"Stock by Attributes" (version 1.5.3). This MOD is ONLY for v1.5.1 ..whaddda?

[oavs]

Does anyone know if there is a "Stock by Attributes" version that actually works with Zenvcart 1.5.3 ?

Curiously why zen developers have created an attribute except NOT included the important aspect of the product attributes (see below)?

Why can't we do this?

Item code=test01 Item attribute 'Large' / 'Red' = Qty = 10
Item code=test01 Item attribute 'Medium' / 'Red' = Qty = 5
Item code=test01 Item attribute 'Small' / 'Red' = Qty = 8

[RodG]

Does anyone know if there is a "Stock by Attributes" version that actually works with Zenvcart 1.5.3 ?

I've got the latest version running on at least one site using ZenCart V1.5.3 ... I don't *recall* having to do anything special to get it to work.

Curiously why zen developers have created an attribute except NOT included the important aspect of the product attributes (see below)?

Why can't we do this?

Item code=test01 Item attribute 'Large' / 'Red' = Qty = 10
Item code=test01 Item attribute 'Medium' / 'Red' = Qty = 5
Item code=test01 Item attribute 'Small' / 'Red' = Qty = 8

It can't be done for the simple reason it hasn't been coded for it. Whether there is an *actual* reason for it is something that I can't answer, but I can say that doing this will probably have a huge hit on performance, and then there's the question of how far should this be taken?

For example, should it also cater for:

Item code=test01 Item attribute 'Large' / 'Red' / 'Blue Buttons' = Qty = 10
Item code=test01 Item attribute 'Medium' / 'Red' / 'Green Buttons' = Qty = 5
Item code=test01 Item attribute 'Small' / 'Red' / 'Black buttons' = Qty = 8

That's 27(?) variants of single product.

or perhaps....
Item code=test01 Item attribute 'Large' / 'Red' / 'Blue Buttons' / 'Green Stripes' = Qty = 10
Item code=test01 Item attribute 'Large' / 'Red' / 'Blue Buttons' / 'Yellow Stripes' = Qty = 10
etc, etc......

That's 256(?) variants of a single product...

Just something to think about..

Cheers
RodG

[twitchtoo]

Yes, RodG has it right, the logic behind the entire product/attribute system is what is the problem. It needs to be developed from the ground up with a dynamic matrix instead of a static lookup loop. The loop is a killer on processing times.

[dbltoe]

May he rest in peace, Conor was close.

[twitchtoo]

May he rest in peace, Conor was close.

Ask me nicely and I'll rewrite it.

[oavs]

Oh yes, I can see your point RodG

On my version 1.5.3 did not work . After uploading all the files, I had white screen on the installation screen and none of the other pages worked either. All there was a white screen. So painfully replaced all the files. Hate it when plugin spreads it self all over the place.

[izzysoup]

Oh yes, I can see your point RodG

On my version 1.5.3 did not work . After uploading all the files, I had white screen on the installation screen and none of the other pages worked either. All there was a white screen. So painfully replaced all the files. Hate it when plugin spreads it self all over the place.

Oh my, I have spent two hours trying to find a solution to get 'stock by attributes' to work properly on 1.5.3. I see some core files have changed significantly from 1.5.1 to 1.5.3 which SBA relies on. I am fairly new to Zen Cart and indeed programming in general, I think my upgrade to 1.5.3 is on hold until I can get this modification to work or it is upgraded.

Does anyone know of an alternative to SBA? As almost all our products have stock by variation and as drop-shippers, we also need the facility to update these 'stocked attributes' via a csv upload.

Many thanks, Izzy

[RodG]

Oh my, I have spent two hours trying to find a solution to get 'stock by attributes' to work properly on 1.5.3. I see some core files have changed significantly from 1.5.1 to 1.5.3 which SBA relies on.

It is true that some of the core files have changed between V1.5.1 & V1.5.3 and that the SBA module relies on these files to function.
Now, although I had no problems with SBA working with ZenCart V1.5.3 I have to admit that I *didn't* use the modified core files from the SBA distribution. The reason being is that the site I installed it on already had other modifications needed by other addons, so this meant I needed to look at the changes to the code modified for SBA and make those same changes/additions to my already modified core files. IOW the original ZenCart V1.5.3 core files needed different modifications for two different add-ons.

Whilst doing this I'd noted that the SBA had less modifications needed than the other add-on - In fact the parts of the code it modified were quite clearly marked and easy to follow - So although I had an already modified code that needed these further modifications for SBA it was actually quite a simple thing to do.

I'm guessing that you had problems because you simply replaced the original zencart files with the SBA modified ones. I can certainly appreciate that this is generally the simplest and easiest route to take, it isn't the *best* route. If you need to depend on this replacement method it is only a matter of time before you'll end up installing yet another module that also changes these same files and you'll find it impossible to get all of the add-ons to play nicely together. It is for this reason I urge you to learn how to identify the changed needed by any given module so that you can merge the changes yourself if or when necessary.

I fully appreciate that you may be quite new to ZenCart and programming, and as such, I wouldn't normally be suggesting this to you. However, as stated, the changes needed for the SBA module are *clearly* marked in the pre-modified files that are supplied with the download zip, and even a relatively new Zenner with just a little coding experience *probably* won't have too much of a hard time doing a manual merge. Not all other modules make it quite this easy, and this makes using SBA as a near perfect setting to learn how to do the manual merges.

If you can't, or don't want to go this route I fully understand. I'm not trying to disparage you in any way. These kinds of edits and changes really aren't suited for everyone (and they don't need to be), BUT if you do wish or plan to increase your skill level in this regard I do encourage you to give it your best shot... I won't call this a 'baby step' - It is more like a jump... but a jump in the right direction IF ZenCart and programming are in you long term plans for the future. If you don't have long term plans for ZenCart development then please ignore all that I've said, as it isn't applicable to your plans or needs.

Cheers
RodG

[dw08gm]

Ask me nicely and I'll rewrite it.

It would be great if SBA could be optionalised for critical path or finite element analysis, since it is not always the final product that needs tracking but critical individual components that make up one or more products. For instance, Tshirts printed with pre-made transfers, such as iron-on transfers. It may not be the final printed Tshirt that needs to be tracked but the number of pre-made transfers of a particular design that can be applied to a Tshirt, in fact any garment or strata. If you only offered one style of Tshirt in four sizes and two colours, but had 50+ transfer designs, it is better to make the design of the transfer the product and make the Tshirt properties the attributes. But then what happens when the same transfer can be applied to other garments and/or strata. It is such a messy thing.

[twitchtoo]

It would be great if SBA could be optionalised for critical path or finite element analysis, since it is not always the final product that needs tracking but critical individual components that make up one or more products. For instance, Tshirts printed with pre-made transfers, such as iron-on transfers. It may not be the final printed Tshirt that needs to be tracked but the number of pre-made transfers of a particular design that can be applied to a Tshirt, in fact any garment or strata. If you only offered one style of Tshirt in four sizes and two colours, but had 50+ transfer designs, it is better to make the design of the transfer the product and make the Tshirt properties the attributes. But then what happens when the same transfer can be applied to other garments and/or strata. It is such a messy thing.

I believe the biggest problem is the belief (currently supported by the old code) that attributes are treated differently than products. It's simply a relationship or connection between the product and the attribute that needs to be stored.

In that type of model all data would be recorded for products as it is for attributes, and therefore the type of reporting you're looking for would be a click away.

That too means the output loops wouldn't be constantly 'searching' through the attributes.

Some would then argue there would be a 'problem' managing the relational data. That's pretty easy too, build a static display that clearly displays the db content with simple management tools like single/group select, move, delete etc.

This type of 'static' matrix ensures that all components of the system always work. Product/Attribute management, Bulk import/export, Reporting etc.

It also would allow anyone with an existing cart to output their data, upgrade to the newest version of Zen Cart, install the new 'attributes' module and import their data.

Two elements are required to 'kick start' this, time and money. Time I have.