Jump to content
Sign in to follow this  
joeyjgarcia

Attribute Sets Contribution

Recommended Posts

I would like to get another beta tester for version 5 before I release it. Chris graciously caught a lot of errors on my part and after I made the changes it is running but I would like to see someone take this latest version of my code and install it before I release it to the world.

 

Thanks.

 

Joey

 

 

Coding and my (limited) testing is now complete for version 5.0.  Now I just have to update the install instructions.

 

I have to say, I am pretty excited about this version because it just feels like it is done right!  I think you all will like it. :-)

 

I actually removed old code, so upgrading might be a little tricky but I will try and do a super good job on the install instructions and the upgrade (4 to 5) instructions.

 

Give me at least a week.

 

Joey

Share this post


Link to post
Share on other sites
I would like to get another beta tester for version 5 before I release it.  Chris graciously caught a lot of errors on my part and after I made the changes it is running but I would like to see someone take this latest version of my code and install it before I release it to the world.

 

Thanks.

 

Joey

Not that many errors Joey! Just thought I'd mention for those in need of this contrib - for Beta code it is very clean with good install instructions - if you need this stuff don't be afraid to beta it for Joey.

Only caveat is that it currently needs register globals on as described previously.

 

Chris.

Share this post


Link to post
Share on other sites

Version 5 - Option Values Sort

 

Joey,

I realise it is not your priority but I have a thought rattling around my head & thought I'd run it by you in case I am missing something in your thinking.

The sort function you provide currently records the option value sort against every individual product attribute. Should it not really be recorded against the option to option value link?...or is there a scenario I have not thought of?

 

E.g. assuming we are using the products_options_values_to_products_options table correctly then would it not be the place to record the sort order?

 

For example (not using column names etc.) we have:

 

Option name: Lense

 

Option value: +1

Option value: +2

Option value: +3

 

The products_options_values_to_products_options table records (using id's of course):

 

Lense +1

Lense +2

Lense +3

 

Which with a sort column (eg showing reverse sort order) becomes:

 

Lense +1 sort 3

Lense +2 sort 2

Lense +3 sort 1

 

Therefore a join with products attributes provides the sort order for the products_options_values_to_products_options

 

Is there some scenario where it is useful to have this in the products_attributes table? I'm asking to decide if I need a product_id the custom table approach I mentioned - currently I think not as with current scenarios that I can foresee it seems to create redundancy.

 

Basically do we ever need the facility to specify the sort for every single product.attribute or is it good enough to specify the sort for option values and assume it will be the same for all products that use them.

 

Any thoughts?...anyone else care to comment?

Cheers

Chris.

Edited by toasty

Share this post


Link to post
Share on other sites
I'm not ignoring you, I'm just puzzled.  Your url has what it needs.

 

I was working with Chris on some beta testing on my contribution's version 5 and he made me aware that I rely on a setting for register_globals set to "on", which means that  the variable you see in the url below called "attset_id" is automatically used in my code like this $attset_id instead of explicitly setting it to a variable like this $HTTP_POST_VARS['attset_id'].  This may be why your $attset_id is not working.

 

To check this setting make a file called phpinfo.php and put inside this file this line:

 

<?php

echo phpInfo();

?>

 

Display this page in your browser and report back what your "register_globals" setting says, "on" or "off"?

 

Joey

 

Hi Joey, my Register Globals are indeed off, and I use the Register Globals patch.  If there is an edit you'd like me to try, I'm happy to do so!  Thanks for your help!  This is a great contribution!

 

Share this post


Link to post
Share on other sites
Not that many errors Joey! Just thought I'd mention for those in need of this contrib - for Beta code it is very clean with good install instructions - if you need this stuff don't be afraid to beta it for Joey.

Only caveat is that it currently needs register globals on as described previously.

 

Chris.

 

Both sites that use this contrib are on the same host, which requires Globals Off. Joey, if you need a beta test done under these conditions, I can do that... provided it doesn't break the stores, which are now live. (woo woo! my first osCommerce adventures!)

Share this post


Link to post
Share on other sites
Both sites that use this contrib are on the same host, which requires Globals Off.  Joey, if you need a beta test done under these conditions, I can do that... provided it doesn't break the stores, which are now live.  (woo woo! my first osCommerce adventures!)

 

Hmmm Beta + Live Store = tempting fate Janet. Can't you copy your live store to another spot and try it safely first?

Regarding register globals off I have it working but it was a bit tricky to find some of the required var changes. Now that we know the misbehaving vars Joey is updating them. When your ready to go with it I'm happy to help spot any problems as it is fresh in my mind at the moment; although I'm sure Joey is on the case.

 

cheers

Chris.

Share this post


Link to post
Share on other sites
Hmmm Beta + Live Store = tempting fate Janet. Can't you copy your live store to another spot and try it safely first?

Regarding register globals off I have it working but it was a bit tricky to find some of the required var changes. Now that we know the misbehaving vars Joey is updating them. When your ready to go with it I'm happy to help spot any problems as it is fresh in my mind at the moment; although I'm sure Joey is on the case.

 

cheers

Chris.

 

Yeah, that's why I mentioned it's live! :thumbsup: If I make a copy of the site to a /working directory on the same host, will that work? Will it confuse the database?

 

I've been meaning to find this out anyway, because the clients needs Featured Products installed and I was hoping not to rock the boat!

Share this post


Link to post
Share on other sites
Yeah, that's why I mentioned it's live!  :thumbsup:  If I make a copy of the site to a /working directory on the same host, will that work?  Will it confuse the database?

 

I've been meaning to find this out anyway, because the clients needs Featured Products installed and I was hoping not to rock the boat!

 

Yeah it should easy enough. When I do this I work it out as I go along (so it can't be difficult!). Just copy the catalog (assuming admin is in catalog).

From memory its mainly the config file that needs updating to reflect correct dir's etc.

Because Joeys latest incarnation requires an osC table to be alterred you might want to copy the db too (assuming you have access to create another one). Again its really easy, especially if your using phpmyadmin or similar.

Alternatively I'm pretty sure I have just copied the db dir at file level and called it something else, (eg copy shopx and call it shopy), then create a new db user with releavnt permissions for the new shopy db using the mysql root user.

Sounds a lot but it really isn't. Should take you 15 mins!

 

Make sense?...ish

 

cheers

Chris.

 

Specific answer to your question: Technically you could have two shops accessing the same db - but I would not advise it as osC is not Transaction oriented and it could get messy. i.e. two shops simultaneously doing the same thing might not be handled well.

Edited by toasty

Share this post


Link to post
Share on other sites
Make sense?...ish

 

cheers

Chris.

 

Specific answer to your question: Technically you could have two shops accessing the same db - but I would not advise it as osC is not Transaction oriented and it could get messy. i.e. two shops simultaneously doing the same thing might not be handled well.

 

 

Yep, I'll give it a shot when I do the featured products. Just have to reload phpmyadmin for the time being...

Share this post


Link to post
Share on other sites

I have a feature question regarding this contribution. It may have been touched on, but after wading through all the posts my head hurts a little.

 

Here is what I am trying to accomplish...

 

Processor

-Pentium 4 2.8GHz

-Pentium 4 3.0GHZ

 

Memory

-512mb PC3200 DDR400

-1GB PC3200 DDR400

 

Hard Drive

-80GB SATA

-100GB SATA

-120GB SATA

 

I want to be able to sort the Processor, Memory and Hard Drive headings the way I want. So lets say I want it to be Memory, Processor, then Hard Drive. Is this possible with this contrib?

 

I would also like to sort the other items as well under each one of the headings. So I could have:

 

Hard Drive

-100GB

-120GB

-80GB

 

Is this possible as well? I am looking for something with that flexibility.

 

I know there are contributions for customizing computers, but they are not supported any longer. I am only going to have a couple different computers so I was thinking of just setting up attributes instead.

 

Any info would be greatly appreciated.

 

Thanks,

Zickarena

Share this post


Link to post
Share on other sites
I want to be able to sort the Processor, Memory and Hard Drive headings the way I want.  So lets say I want it to be Memory, Processor, then Hard Drive.  Is this possible with this contrib? 

 

 

So in osC terms you want to be able to sort

1. The Option Names: e.g. Processor, Memory, Hard Drive

and

2. The Option Values: e.g. 100GB, 120GB

 

In short this contribution offers the ability to group option values into sets and then order them (by giving them a weighting). Very nicely done too - very user friendly.

 

This contrib does not offer sorting of the Option Names. There is one that does that somewhere but I can't remember what it is. I just did it myself in the end.

 

Hope that helps a bit.

Share this post


Link to post
Share on other sites

 

NOPE!

I wrote my previous post very carefully.

Products (what your thread refers to e.g pentium I, Pentium II) have attributes [which are made up of options (which have names) and each option name (eg Hard Drive) may have a value or number of values associated with it (e.g. 20GB, 30GB etc.).] - you can see this in action in Product Attributes in the Admin section of osC.

 

The link you gave is for a Product sort - not the same at all.

 

Try this - I THINK these are what you need (but I do not know anything about it or if it will run with Attribute sets or not).

 

http://www.oscommerce.com/community/contri...y,3/search,sort

 

or try this

 

http://www.oscommerce.com/community/contri...rch,sort+option

Share this post


Link to post
Share on other sites

I'm having this problem because of my server's register_globals set to off, how can I adjust this contribution to not require register globals set to on?

 

Thanks so much

 

 

I'm not ignoring you, I'm just puzzled.  Your url has what it needs.

 

I was working with Chris on some beta testing on my contribution's version 5 and he made me aware that I rely on a setting for register_globals set to "on", which means that  the variable you see in the url below called "attset_id" is automatically used in my code like this $attset_id instead of explicitly setting it to a variable like this $HTTP_POST_VARS['attset_id'].  This may be why your $attset_id is not working.

 

To check this setting make a file called phpinfo.php and put inside this file this line:

 

<?php

echo phpInfo();

?>

 

Display this page in your browser and report back what your "register_globals" setting says, "on" or "off"?

 

Joey


rkoechel2004

Share this post


Link to post
Share on other sites
I'm having this problem because of my server's register_globals set to off, how can I adjust this contribution to not require register globals set to on?

 

Thanks so much

 

Ryan

In fact the attset should be $_POST['attset'].

I cannot give you the full fix as my code is not fully tested. Joey needs to bring it up to speed if you want code supplied. I'm too busy just now to do the prep work.

 

Regarding how to fix it this my strategy for using register_globals contrib is as follows:

 

If you use something like Dreamweaver (if you don't you get something!) (and you have already installed register_globals contrib - which I assume you have) then do a global search and replace on ALL files in osC as follows:

1.

search: $HTTP_POST_VARS

replace with: $_POST

 

2.

search: $HTTP_GET_VARS

replace with: $_GET

 

when you have done that there are two or three variables that Joey uses without any declaration at all. EG the attset variable he mentioned. It should say $_POST['attset']

 

I'm afraid I can't remember the others and did not note them as I was a bit side tracked with a corruption problem I was fixing at the time.

 

If you have a go and use the code the Register_Globals contrib gives you to put in your application.top file to identify the incriminating vars you should find there only two or three more.

 

If you get stuck (having done some debugging) post here and I'll try to help identify the culprit. Hope that helps some. Its worth the effort if you need sets - good contrib.

Chris.

Share this post


Link to post
Share on other sites

As a side note while I try and make this register_globals off compatible. This issue does not arise when inserting a new attribute set. It only happens when I try to edit or delete an attribute set.


rkoechel2004

Share this post


Link to post
Share on other sites

I've putting it off, but I'll make it handle registered globals set to "off". Shoot, just when you think you're done something else creeps up. [heavy sigh!]

 

I let you know when I get this done, it shouldn't take too long.

 

A beta tester that has registered globals off would be nice.

 

Joey

 

 

I'm having this problem because of my server's register_globals set to off, how can I adjust this contribution to not require register globals set to on?

 

Thanks so much

Share this post


Link to post
Share on other sites

Thanks, I'll look into what I did different there. It may save me some time.

 

Joey

 

 

As a side note while I try and make this register_globals off compatible.  This issue does not arise when inserting a new attribute set.  It only happens when I try to edit or delete an attribute set.

Share this post


Link to post
Share on other sites

Ryan/Chris:

 

With due respect, Chris I don't think the $HTTP_POST_VARS variables is the problem, I think it is when I use a variable without formally coverting it to a variable. I.e., register_globals="on" does it for me, with register_globals="off" requires it to be done explicitly. So, you are correct is substituting $attset for $_POST['attset'] or $HTTP_POST_VARS['attset'] which is the same thing the former is just the newer way to do it.

 

I really, really appreciate your help answering some of these questions, and finding bug because it was an assumption of mine for a long time and there probably have been many people frustrated by this.

 

Thanks again Chris.

 

Joey

 

 

Ryan

In fact the attset should be $_POST['attset'].

I cannot give you the full fix as my code is not fully tested. Joey needs to bring it up to speed if you want code supplied. I'm too busy just now to do the prep work.

 

Regarding how to fix it this my strategy for using register_globals contrib is as follows:

 

If you use something like Dreamweaver (if you don't you get something!) (and you have already installed register_globals contrib - which I assume you have) then do a global search and replace on ALL files in osC as follows:

1.

search: $HTTP_POST_VARS

replace with: $_POST

 

2.

search: $HTTP_GET_VARS

replace with: $_GET

 

when you have done that there are two or three variables that Joey uses without any declaration at all. EG the attset variable he mentioned. It should say $_POST['attset']

 

I'm afraid I can't remember the others and did not note them as I was a bit side tracked with a corruption problem I was fixing at the time.

 

If you have a go and use the code the Register_Globals contrib gives you to put in your application.top file to identify the incriminating vars you should find there only two or three more.

 

If you get stuck (having done some debugging) post here and I'll try to help identify the culprit. Hope that helps some. Its worth the effort if you need sets - good contrib.

Chris.

Share this post


Link to post
Share on other sites

This can be done somewhat easily, but I'm not up for it right now.

 

Basically, it can be done like this. (I know Chris won't like this solution because it modifies an osCommerce table, I'm willing to accept the risk but I could understand if someone would not. This is how the sort order works in my contribution, which Chris changed for his site.)

 

1) Create a sortOrder field (int) in the products_options table

 

2a) Then build an interface to set the values of this field

 

or

 

2b) Open phpMyAdmin and use that interface to set the values for this new field

 

3) Find the SQL code in the product_info.php page that calls the products_options table and add (or change) a ORDER BY clause that looks like this: "ORDER BY products_options.sortOrder".

 

Before you make this change you can practice using this ORDER BY clause in the phpMyAdmin tool just to see how it works, it is a harmless clause that is usually put at the very end of a SQL query, like this select * from products_options op WHERE 1 ORDER BY op.sortOrder

 

the "op" is a SQL short cut abbreviation for the table name, and the "WHERE 1" part is required but doesn't do anything, kind of like saying "WHERE true".

 

I hope this helps a little.

 

Joey

 

 

 

NOPE!

I wrote my previous post very carefully.

Products (what your thread refers to e.g pentium I, Pentium II) have attributes [which are made up of options (which have names) and each option name (eg Hard Drive) may have a value or number of values associated with it (e.g. 20GB, 30GB etc.).] - you can see this in action in Product Attributes in the Admin section of osC.

 

The link you gave is for a Product sort - not the same at all.

 

Try this - I THINK these are what you need (but I do not know anything about it or if it will run with Attribute sets or not).

 

http://www.oscommerce.com/community/contri...y,3/search,sort

 

or try this

 

http://www.oscommerce.com/community/contri...rch,sort+option

Share this post


Link to post
Share on other sites
Should it not really be recorded against the option to option value link?

 

I don't understand this phrase? I'm not sure what you mean by "recorded"? Are you saying that I should limit the ORDER BY clause to attribute values just for that Option rather then for all Options? I could agree to that.

 

I added this feature in because people requested it, I don't need it for my store. You asked it every attribute needs to have every attribute sorted, and I guess some people do. Just like some peopl need their options sorted as well.

 

Your example confused me, were the Option Values the actual values or the prefix? I think in sizes, since my store is about t-shirts, can you try it again with sizes?

 

Not sure how your example became reverse sorted.

 

 

 

Joey

 

 

Version 5 - Option Values Sort

 

Joey,

I realise it is not your priority but I have a thought rattling around my head & thought I'd run it by you in case I am missing something in your thinking.

The sort function you provide currently records the option value sort against every individual product attribute. Should it not really be recorded against the option to option value link?...or is there a scenario I have not thought of?

 

E.g. assuming we are using the products_options_values_to_products_options table correctly then would it not be the place to record the sort order?

 

For example (not using column names etc.) we have:

 

Option name: Lense

 

Option value: +1 

Option value: +2

Option value: +3

 

The products_options_values_to_products_options table records (using id's of course):

 

Lense +1

Lense +2

Lense +3

 

Which with a sort column (eg showing reverse sort order) becomes:

 

Lense +1 sort 3

Lense +2 sort 2

Lense +3 sort 1

 

Therefore a join with products attributes provides the sort order for the products_options_values_to_products_options

 

Is there some scenario where it is useful to have this in the products_attributes table? I'm asking to decide if I need a product_id the custom table approach I mentioned - currently I think not as with current scenarios that I can foresee it seems to create redundancy.

 

Basically do we ever need the facility to specify the sort for every single product.attribute or is it good enough to specify the sort for option values and assume it will be the same for all products that use them.

 

Any thoughts?...anyone else care to comment?

Cheers

Chris.

Share this post


Link to post
Share on other sites

I just uploaded version 5.0. Please give it a try and let me know how it works.

 

Upgraders be cautious! Replace the old code with the new code just to be sure!!!!

 

Joey

Share this post


Link to post
Share on other sites

Joey you are correct because I use the $HTTP_POST_VARS throughout oscommerce without issue. along with GET. I will of course be willing to test any solutions you have for this...send them to me and i'll load them to my test site.

 

Thanks so much for your response to my issues.

 

 

Ryan Koechel

 

 

 

Ryan/Chris:

 

With due respect, Chris I don't think the $HTTP_POST_VARS variables is the problem, I think it is when I use a variable without formally coverting it to a variable.  I.e., register_globals="on" does it for me, with register_globals="off" requires it to be done explicitly.  So, you are correct is substituting $attset for $_POST['attset'] or $HTTP_POST_VARS['attset'] which is the same thing the former is just the newer way to do it. 

 

I really, really appreciate your help answering some of these questions, and finding bug because it was an assumption of mine for a long time and there probably have been many people frustrated by this.

 

Thanks again Chris.

 

Joey


rkoechel2004

Share this post


Link to post
Share on other sites
Ryan/Chris:

 

With due respect, Chris I don't think the $HTTP_POST_VARS variables is the problem, I think it is when I use a variable without formally coverting it to a variable.  I.e., register_globals="on" does it for me, with register_globals="off" requires it to be done explicitly.  So, you are correct is substituting $attset for $_POST['attset'] or $HTTP_POST_VARS['attset'] which is the same thing the former is just the newer way to do it. 

 

I really, really appreciate your help answering some of these questions, and finding bug because it was an assumption of mine for a long time and there probably have been many people frustrated by this.

 

Thanks again Chris.

 

Joey

 

Joey,

Its a pleasure Joey - argue your side without worry of offense :thumbsup:

Your points:

1.

I've putting it off, but I'll make it handle registered globals set to "off". Shoot, just when you think you're done something else creeps up. [heavy sigh!]

....cheer up, it'll be a piece of cake for you Joey - its not far off anyway, only two or three vars (max) are misbehaving!

 

2. To $HTTP or not to $HTTP

 

Regarding $HTTP_????_VARS or $_???? you are correct that your code will run with the former (I think, and on the assumption you explicitly use as previously discussed) and register_globals off, however it is important to note (IMHO) that there are other differences between the two.

 

$HTTP_POST_VARS (otherwise known as variable arrays) is now depracated from php. In php 5, php may be configured not to allow variable arrays to reduce server overhead. Your code (as is) in that situation may not run. For the sake of a search and replace why not do it the correct way (in particular as php5 is now starting to find its way on to isp servers)?...after all it is all in the interest of good coding and good security.

 

Also, in some cases $HTTP_????_VARS variables need to be explicitly declared as global (say in a function), whereas $_???? Are autoglobal, or superglobals, so they do not need declaring as they are automatically in scope anywhere.

I have found with osC (and contributions) there are sometimes occurences of HTTP_????_VARS requiring a global declaration when register_globals is off - it is not always obvious, but you suddenly find things not working or data missing for no reason. This is why I do a search and replace and set all HTTP_????_VARS to $_???? Variables - then I have no worries as I know they are all superglobals; in scope wherever they are despite register_globals being off. There is no down side to this approach that I know of.

osC will run without this (...aha!...or will it?...well that depends....) - personally I like certainty.

 

3. Sort Order - I'll get back on this when I have a few moments spare. Essentially I am drawing your attention to the difference between the options (that we need to order) and the product attributes (which we don't - the options are ordered). The order belongs to the options, not the product, and as there are many many more attributes why create al that redundancy. I'll give example to illustrate later. (p.s. By the way, I have planned the change but not implemented yet!)

 

Just MHO's of course - folk may and will choose to do their own thing.

 

Cheers

Chris

Share this post


Link to post
Share on other sites

I'll probably post a version 5.1 just to replace the HTTP_POST_VAR with _POST variables, because you are correct but HTTP_POST_VAR is all over osCommerce.

 

I welcome your comments, you make very good comments and I believe my contribtion will be better with them. Also, you're keeping me encouraged.

 

I want to work on your comment on Options and Sort Order some time.

 

Thanks.

 

Joey

 

 

Joey,

Its a pleasure Joey - argue your side without worry of offense  :thumbsup:

Your points:

1.

I've putting it off, but I'll make it handle registered globals set to "off".  Shoot, just when you think you're done something else creeps up.  [heavy sigh!]

....cheer up, it'll be a piece of cake for you Joey - its not far off anyway, only two or three vars (max) are misbehaving!

 

2. To $HTTP or not to $HTTP

 

Regarding $HTTP_????_VARS or $_???? you are correct that your code will run with the former (I think, and on the assumption you explicitly use as previously discussed) and register_globals off, however it is important to note (IMHO) that there are other differences between the two.

 

$HTTP_POST_VARS (otherwise known as variable arrays) is now depracated from php. In php 5, php may be configured not to allow variable arrays to reduce server overhead. Your code (as is) in that situation may not run. For the sake of a search and replace why not do it the correct way (in particular as php5 is now starting to find its way on to isp servers)?...after all it is all in the interest of good coding and good security.

 

Also, in some cases $HTTP_????_VARS variables need to be explicitly declared as global (say in a function), whereas $_???? Are autoglobal, or superglobals, so they do not need declaring as they are automatically in scope anywhere.

I have found with osC (and contributions) there are sometimes occurences of HTTP_????_VARS requiring a global declaration when register_globals is off - it is not always obvious, but you suddenly find things not working or data missing for no reason. This is why I do a search and replace and set all HTTP_????_VARS to $_???? Variables - then I have no worries as I know they are all superglobals; in scope wherever they are despite register_globals being off. There is no down side to this approach that I know of.

osC will run without this (...aha!...or will it?...well that depends....) - personally I like certainty.

 

3. Sort Order - I'll get back on this when I have a few moments spare. Essentially I am drawing your attention to the difference between the options (that we need to order) and the product attributes (which we don't - the options are ordered). The order belongs to the options, not the product, and as there are many many more attributes why create al that redundancy. I'll give example to illustrate later. (p.s. By the way, I have planned the change but not implemented yet!)

 

Just MHO's of course - folk may and will choose to do their own thing.

 

Cheers

Chris

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×