668 replies to this topic

[kymation]

This addon is being developed to allow the addition of an unlimited number of
specifications to the site's products. These can be used for:
1. A table of specifications on the Product Info page.
2. A comparison table showing the specifications of a group of products.
3. A set of filters to allow the customer to show only products that meet
certain criteria. This could be all AGP video cards with 256MB of memory, the
parts for a 1992 Yugo, or anything else you might want to set up.

================================================================================
                               *****WARNING****  
                 -=Development Code=-
This code is currently under development. Consider this an early Alpha release
at best. Parts of the code are extremely buggy, and the rest is incomplete. Or
missing altogether. Don't even think of installing this on anything except a
development machine. Also, don't install it if you are not at least moderately
familiar with PHP and MySQL and willing to at least look at both. This addon
will be replaced with a new one when the code is ready for release.
================================================================================

Code in a minute....

[kymation]

The code is here.

Please post any suggestions, code snippets, and things you might want to do with this. I promise to consider any additional requirements (although I don't promise to code them.) I also welcome anyone who wants to help with this project.

I think this could be useful to anyone who sells technical products, from computers to auto parts to whatever. If you fit in this category, please participate. You won't necessarily get the features that you need if I don't know about them. I am trying to make this as generic as possible, but I can't think of everything.

Currently, the database design is done (lthough subject to change.) The SQL and a relation diagram are included. The Specifications display on the products Info page should work. The Admin pages are mostly done but buggy. The Comparison page is barely started. The Filters code is mostly just prototype code (based on an older mod that wasn't all that versatile.)

Yes. there's still a lot of work to do here. I'm doing this in my spare (hah!) time, so don't expect it tomorrow.

Regards
Jim

[snowbird]

kymation,

thanks for starting up this project. i think this addon will be in top 10 when it becomes stable. i will try current code base in my local development server and throw some early comments here afterwards. also i can contribute to this project

[kymation]

Thanks for the good words. The code is a mess right now. It's actually worthless, so don't bother. I'll be putting up a new version in a bit with some of the bugs fixed. It still won't be worth the bother, but more of the bugs will be gone. The code is only there because it's required to have code to discuss the development here.

What I really need right now is requirements. What do you need this to do? What features would you like to see? Options? Anything at all to help guide the process. I've got a bunch of ideas, but I don't know if I'm the only one who wants those. I'd much rather design things in than find out after it's all done and have to make major changes.

Help with the coding will also be quite welcome. There are pages that could be developed separately, once I get the database design stable that is. If you'd be willing to work on something like the Comparison page, just let me know.

Regards
Jim

[burt]

Haven't had the time to test this out at all, but it sounds interesting...

Linked Options/Attributes - possible?  Eg;  colour red only available in size L.  THerefore if they choose M as the size, red should disappear.

[kymation]

That's pretty much the way the prototype worked. Except it's not attributes in the osCommerce sense; the data fields are completely separate. Linking it to Options/Attributes for a product instead of just to the product could be useful. I'll have to think about how to make that work.

Regards
Jim

[kymation]

I've added an updated package to the code distribution. Note that the code is still pretty badly broken and unusable.

The database design has been changed to make filters a bit more rational. This is not final by any means, but it's getting there. I've also done some more work on the Admin side.

Comments or questions on the design are still welcome. Please let us know what you think.

Regards
Jim

[bruyndoncx]

could you expand on how ithis different form the category fields contribution ?

[kymation]

Category Fields adds extra data fields to the Products Info page. In that respect it's very similar. I intend some more options on that page, but otherwise the result will be the same. The database design is also similar, in the areas where it matches, although I've tried to make this one a bit more generic.

Category Fields lacks the ability to generate a comparison page for the products in a category. It also lacks the filters that can be used to restrict the product listing to only those products meeting customer-selected criteria. These two features were the reason I decided to code this monster. I've done similar modifications before, but they weren't generic enough to be reusable. I'm tired of custom coding these things, so I decided to create something that can be reused for a variety of different sites.

Regards
Jim

[bruyndoncx]

kymation, on May 26 2009, 08:05 PM, said:

Category Fields adds extra data fields to the Products Info page. In that respect it's very similar. I intend some more options on that page, but otherwise the result will be the same. The database design is also similar, in the areas where it matches, although I've tried to make this one a bit more generic.

ok, think i got it.

Quote

Category Fields lacks the ability to generate a comparison page for the products in a category. It also lacks the filters that can be used to restrict the product listing to only those products meeting customer-selected criteria. These two features were the reason I decided to code this monster.

I've coded these things quite some time ago, the compare contribution is still around, but i don't think it should be used as the design is not flexible enough. i think it should probably be modelled after the shopping_cart class.
Filters (my version works but sucks as it is too memory intensive) I personally would like it so they can be bookmarked, and some ajax UI functions to cut down on long lists.
I've been pondering to add category fields or not, I have currently static attributes which I can use easily for fixed text fields.

Haven't looked at your code yet, been busy, but I'll definitely following this thread,

Carine

[snowbird]

Jim
I have a few ideas

Adding a hint field to the specification_description table could make more friendly in understanding that extra specification
Also specification field can be dropdown, checkbox,etc  type various form input element. By adding extra table field for this?

[kymation]

snowbird, on Jun 1 2009, 09:30 AM, said:

Jim
I have a few ideas

Adding a hint field to the specification_description table could make more friendly in understanding that extra specification

I had intended to use the specification_description field for that. It really doesn't have any other practical use. Unless you can think of something?

Quote

Also specification field can be dropdown, checkbox,etc  type various form input element. By adding extra table field for this?

This would be useful where the specification field has a small set of specific values, so it would need to be optional. Interesting idea. I'll add that to the list.

Thanks for the ideas!

Regards
Jim

[snowbird]

Jim,
For the hint text using specification_description field is okay, thats good.

For the 2nd idea field type can be set and has fixed content in admin entry by adding something seperated ie. "dropdown:256MB|512MB|1024MB" or "checkbox:"Yes|No" for multiple fixed choices in admin product update for the product entry operators.

Otherwise ie. if we add a label like "Memory Size" then operators who add/update product in admin can enter 256MB or 256 MB by hand for the same category products by accident. We have to fix the selection items for them. Off course you are right, just for the short list of items can be useful and practical.

Edited by snowbird, 03 June 2009 - 03:24 PM.

[kymation]

To make things more complex (Ha!) the MB should be set up as a suffix, making one more way for the code to get entered wrong. Yes, I've seen this problem before. The solution is not going to be simple. For one thing, it complicates the code in admin/categories.php. I still think this is a good idea, but it may not make it into the code until I can get the design fixed in my head. And, of course, find the time to code it. Time is bing short right now, too.

Thanks for the good comments. If you have any more good ideas, please pass them on.

Regards
Jim

[snowbird]

No, it won't be so complex. By adding an additional field (ie. specification_formentry) in specification_description can make this happen. If it has something in it like "dropdown:256MB|512MB|1024MB" in categories.php field can populated as dropdown and forces operator to select one. If it is empty standard entry field can be displayed as normal

[kymation]

I'm going to do this right. It needs another field to specify the type (pulldown, radio, whatever) and a new table to hold the values. It's a good idea, and it will be added, but not right now. I need to get some other things working first.

Regards
Jim

[JvdP]

Hi Jim,

First off, thanks for starting this contribution. It is exactly what I've been looking for.

I am the webmaster of our own webstore in maternity fashion. My GF, who is the owner of the store, is asking for a smart filtering system. She means: tick several specifications from a menu and only the clothes matching the specifications will be displayed. Naturaly clothes are divided in types, like trousers and skirts. However, if you want all red clothing in size XL the selection is not possible. ... I am sure you know what I mean ...

I understand your contribution is still in development and not to be used in our live store. Sort of speak a "pre-alpha release". I installed the contribution on my development machine and have to say it is very promissing. I surely want to contribute in testing with you and help with the development. Not in the least because I would be able to make sure the contribution fits my needs   .

But of course that's not the primary reason, OsCommerce has become some kind of hobby.

My configuration on the development machine:

Operating System: Windows Vista™ Home Premium (6.0, Build 6002) Service Pack 2

HTTP Server: Apache/2.2.11 (Win32)
PHP Version: 5.2.9-2 (Zend: 2.2.0)
Database: MySQL 5.1.34-community

OsCommerce: oscommerce-2.2rc2a

Register_globals = off (other Apache/PHP variables on request)
Amount of Contributions: 53 (can make a list if you want). If nescessary i can make a clean install for this contribution alone.

-------
First observation:

During installation I have imported the SQL file. As you stated (warned) the options in table CONFIGURATION where added under configuration_group_id = 1610. However, in my version of MySQL, configuration_group_id 888006 was added to table CONFIGURATION_GROUP. 888006 happened to be the auto_increment number in this table. In other words: the SQL script is not in line with the auto_increment rules of my MySQL configuration/version.

After installation, I corrected the database and was able to set the configuration options of this contribution. However with:

	if (SPECIFICATION_SHOW_TITLE_PRODUCTS == 'True' && (SPECIFICATIONS_BOX_FRAME_STYLE == 'Plain' || SPECIFICATIONS_BOX_FRAME_STYLE == 'Simple') ) {
	  echo '<b>' . $specification_box_heading[0]['text'] . '</b>';
	}

I would expect to see at least something with the options set accordingly.

------

OK, found your contribution today so I still have to digg into the code. As well, I am not a PHP expert but tryinmg to be a good amature. If it is possible for you to give us the basics about how you have structured your coding, or.. your intended structure of building this contribution, it will be helpfull to test and give feedback.

Regards,
Jerome

[kymation]

Thanks for the comments. For the development period, I recommend a plain unmodified install of osCommerce 2.2RC2a. There are going to be enough bugs without trying to figure out interactions with other addons. My development box is running Apache/2.2.11/PHP 5.2.9/MySQL 5.1.33 (XAMPP 1.7.1) under WinXP, so you shouldn't see any compatibility issues there. I write everything with all variables strictly declared and filtered, so no Register Globals problems either.

The warning in the SQL file is there for good reason: this happens a lot on modified stores. Some people write PHP scripts to take care of it automatically, but that depends on running your store database with full privileges, which I don't recommend. So I just put a warning in the SQL file and the Readme and leave it up to the person doing the install to change it if needed.

Unfortunately the code you quoted is still badly broken. I've been trying to get the Admin side working, at least for basic functions, before I go write the front end code. I did write a prototype of this, so you'll see some code in there, but it was too specific to the store it was written for. I want something that is general enough to be used for a wide variety of businesses, so that code will need to be rewritten. It's mostly there to remind me of what I wanted to do.

Equally unfortunately, the design is mostly in my head. I posted here to get input from folks like you, so I didn't miss something obvious in my design. This seems to be working well; I've had several helpful suggestions. Getting me to write out a design will be much harder. I did do a database design, which is about as far as it got. That's likely to change a bit based on suggestions above. The coding style is intended to match osCommerce as much as possible. I try to comment things as I go, so you can get some idea from reading the code.

From what you've said, this should work well for your store. That's pretty much what I had in mind for the filters. If you want to see my prototype store with the filters, PM me and I'll give you a link. If you'd like to write up a requirements list, feel free to send it to me or post here.

I haven't been working on this much; life has been getting in the way. I hope to do some more this evening. I'll post an updated version as soon as it's working well enough to be worth doing.

Regards
Jim

[JvdP]

Hello Jim,

As you recommended I have made a new install of osCommerce for testing this contribution.

During installation I saw the following in the SQL script:

INSERT INTO `configuration_group` (`configuration_group_id`, `configuration_group_title`, `configuration_group_description`, `sort_order`,`visible`) VALUES (
NULL , 'Products Specifications', 'Products Specifications configuration options', '1610', '1');

This script does not assign the value '1610' to 'configuration_group_id' but to 'sort_order'. Value 'NULL' which is used in the script results in an auto_increment of 'configuration_group_id'. To make sure 1610 is used, the correct script should be:

INSERT INTO `configuration_group` (`configuration_group_id`, `configuration_group_title`, `configuration_group_description`, `sort_order`,`visible`) VALUES (
'1610' , 'Products Specifications', 'Products Specifications configuration options', '1610', '1');

OK, this was a minor. Hope you'll find time to continue your work on this contribution.

Regards,
Jerome

[kymation]

Thanks; I missed that. I should probably rebuild the SQL file, or at least check it from my database, before I release this. I keep changing things in the development database and forget to fix my errors in the file.

Regards
Jim