Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

dwatson

Archived
  • Posts

    77
  • Joined

  • Last visited

About dwatson

  • Birthday 11/11/1953

Profile Information

dwatson's Achievements

  1. I think this is the answer. Does anyone have a better method? Thanks. I think you were on the right track after all with the low order fee module, but it is a little more complicated than you thought. I was getting hung up with figuring a setup ($0 or $X) per product, rather than a summary of the whole amount. I think my side reaction to use a SQL query to drive it was a better idea than a focus on the attributes array. So, here goes: * Assume that you do not really have (or will have) any real low order fee, and we can use that facility to calculate the setup fees instead. * The algorithm for figuring setup fees can be stated simpler, which lends itself to a SQL query to get it: Charge $ SETUP (the $ SETUP constant is defined as $X) for every unique group of colors in the order, except white. You can calculate a setup total easily using this view of the calculation, as long as you have the groups counted (and subtract 1 for White if its there). * Redo the internals of the ot_loworderfee class in the php file with that name. This way, as long as you specify that the low order fee is displayed and allowed through the admin, then the routines can perform and display their own calculations (ignoring the other settings like ?order fee for orders under? and ?order fee?) since it won't "really" calculate a low order fee -- just use its data structures and variables for display. * The internals of this class would now do a join query on the tables order_products and order_products_attributes tables from the database. The query and its evaluation would return a count of the groups of unique color attributes in the order and whether white was one of them. If white is one of them, subtract 1 from the count, then multiply by $ SETUP.. Put this total into the value that is passed to low order fees. * Rename the label on the order confirmation to something like ?Color setup fees? or whatever you wanted there. That would be a text change somewhere in the files. I think that would do it. I think all you would need to do is replace that ot_loworderfee.php file and change the label text to say ?Color Setup Fees.?
  2. wazu, I am now writing pseudocode documentation on the code base. See the contribution: http://www.oscommerce.com/community/contributions,3078 I have started with application_top.php because it is, well, at the top of every page and brings in all the key functions, classes and constants. I am doing this becuase I will be taking apart and putting back together main pieces of osC for a client, especially the checkout process, and this is best way I know to really learn to do that. What I will do, since I plan all the main parts of the site, is focus today on the parts that you are asking about. This is fine for me -- I don't mind working on it a little out of order. I'll send you the pseudocode (code rewritten as English logic, not computer statements) for that. I'll also take a better look at any relevant contributions. I really should do that before blabbing so much. Can you give me a list of all the contributions that you have looked at at so far re. this? And I'll do a search myself. It sounds like the coding work you need to do is really not that much for someone with the php skills. If I were you, I would very clearly do a one or two page write-up of exactly what you want it to do -- this thread is a good starting point. Skip the technical stuff -- just make it a very clear funcitonal spec. Your first example was good, but maybe do a crude mockup of how you really want (not kludges) to tell the user about these charges (and where) and then how you want them displayed or annotated during the checkout. For example, do you want the products sorted differently on the order confirmation for the color groups? Use the osCommerce checkout screens as a starting point, of course. Next, there are lots of php programmers who work off-site that would do this work. Get a bid up front for what it would cost, how long it would take, etc. From the work I do today on the pseudocode, you should get a good idea of that. Then contract it out. Then, when you get the results, put it on your environment and test it well before you upload it to your production site. This looks non-trivial to me, but certainly not a major project. Because of that, I think you can still figure out how to do it the best way for your customers -- without navigation kludges. I think it would be better for your customers (and your store revenue) to do it the right way, and really not that hard. It just sounds like you don't have the time now to read through all the PHP how-to books yourself.
  3. Pretty much. I think that you are trying hard to judge the setup from the info in a single product-record (or array, which goes into a record). I don't think that can work. If you call the data up as it is, then try to calculate your setup $, you have to go through all that sort, group, traverse stuff every time. Its just a good chunk of logic, but it certainly could be done on the fly. Think of it this way. Every time want to decide whether to charge a setup fee or not, you have to group every product in the cart by color. then you have to figure the first product in the color group. Then you have to set its setup to $.50. Then you have to go through each of the others and set them at $0. Then you have to know when you come to the product for a new color group and set it to $.50, etc. etc. This certainly could be done a number of ways. It just is not as simple as looking at a single product-record and seeing if you should charge a setup for that. You have to know about all the other product-records in the cart (the groups, first ones) to do that. In general, shopping carts assign attributes and their prices one-to-one, to products in the basket. So, someone picks a suitcase -- its $200. Then they choose the attribute or add-on -- "have it monogrammed" and that is an extra $5. So the attribute there has nothing to do with the other products in the cart. In your case, this setup attribute has everything to do with the other products in the cart. Here is another way you could do on the fly: Put in some conditional logic in the checkout for each product to say whether you have already charged a setup for that color. If not, then charge it. If you have, then don't charge it. Again, you are into more complicated logic than just looking at an individual product purchase record. You are tracking what has been going on with the other products in the cart before you charge the setup. You have to have a variable to track whether that color has been charged a setup, etc. This seems just as complicated as the array/database stuff. My feeling about this is that it is not a php newbie project. If you wanted to read something like the O'Reilley book on PHP and MySQL, then you could certainly tackle it. If I looked hard at the code and data structures, I could proably find the easiest way. But no matter what, it involves setting a price based on what has been charged for other products in the cart. Its not an atomic judgement. I know PHP pretty well, but I'm still learning osC. So don't take this as gospel. But it seems logical to me.
  4. Come to think of it, if osC always uses codes here for attributes, I would also create extra setup fields (in the array and db) that hold codes. Then, where osC creates ancillary tables to join (that have the values), I would do the same. The reason for following the osC exact data structure, is that osC will probably handle everything automatically (except the color sort) in all of its display routines. It is probably expecting to see every attribute with the same data structure. I think if you do try to calculate this setup on the fly during checkout, it will be harder. It is not just an assignment or simple calculation -- it is a sorting & grouping of the records, then a sequential if-then-else traverse of the records to find the first in each group etc. This is a lot of logic. Unless I am mising something, this does not sound trivial at all. I wish I knew of a contribution that handles this. If there isn't one, and you do it, you should release it as a contribution.
  5. I think you are charging the setup for the first red, and not the other reds, so you will have to build some extra data and extra logic into it. There is a sort, then a sequential if-then-else. What this sounds like is creating another, synthetic, attribute for setup. Setup will not be chosen by the user, but rather, calculated by you. So you would have to add the field to the db that osC would normally do after the user selects an attribute. I would just make another array element for setup $ along side of (to pretty much match) the color attribute code. The new value does not have to be a code, of course. It could just be a value like 0 or .50. All this means you have to understand what osC does to create and store a regular attribute, and you have to do it in one routine, automatically, without the user doing anything (after they have chosen color). Of course your code could always figure this out, on the fly, on checkout given the products and colors (and their sort). But doing it up front, like it is another attribute in the db, will probably make it easier. Otherwise, you might have to calculate it multiple times. I would think that you would also want to maintain the color sort on the checkout order confirm. Then the setups will make more sense when you see all the reds grouped together and first one has the setup $. Again, I'm really not reading the code or looking at contributions. I'm just thinking about the logic and algorithms I would see there.
  6. Okay, back from dinner shopping. Sorry about the shorthand. For the <pre> tags, if its inside php, you will have to say echo "<pre>"; var_dump(array name); echo "</pre>"; you have to echo the pre's because they are really html tags, but the var_dump goes right to the screen. I would take a good, hard look at that array that holds the color values and products. Then I would figure out how to sort it by colors. You might want to add an extra element to the array to track the setup fee ($0 or $X for setup). Then, when you have collected all the data nicely, sorted, and lined it up in the array, you can figure out how to write it to the db table, if needed. Then you can make sure it comes out okay with the shopping cart screen, etc. Setup just sounds like an extra price attribute that is calculated above after you do the array manipulation.
  7. Look up the var_dump function in www.php.net. It just dumps the array values to the screen and is great for testing and debugging. You can do fancier dumps with objects, but I don't think you need that. The pre tags around it just make sure the exact text is shown -- meaning the browser does line feeds where there are character line feeds and the array looks readable, indented where appropriate, etc. Put one in your code there and just see what comes out on the screen -- assuming you are working with dev code and not your production site. Oh, backup first. I think your array is going to need an extra value to track the color grouping. I would not be surprised if you had to do some parallel database work too. Also, all this grouping and sorting could be done with SQL statements, if you were tracking all the data in the db tables.
  8. Oh, one trick that might help. After the containing data structure is "filled", put in a <pre>var_dump(--array--)</pre> and take a look at exactly how it is being populated. Then you can adjust it, and figure out what extra calcualtions you then have to do on it. Maybe there is a simple way to do this, but I don't know off the top of my head.
  9. Sorry, I don't have the time to go through and read that code right now. It does not sound like a simple hack to me. You need to keep track of the colors, and then group the products selected within each color choice. It sounds like a different array structure than what osC provides. But I'm not looking at that code right now, so can't say for sure.
  10. If there is not a contribution that can do this, I would just tend to dig into the php code myself. I would think you would have to do that, because this is a special circumstance.
  11. I wanted to start a support thread for the contribution: Code Documentation and Function Reference http://www.oscommerce.com/community/contributions,3078 I few people reading the announcement wanted to see a support thread to contribute to. Any comments on anything in the the document would be appreciated.
  12. I don't know of a contribuiton. But maybe you could put your basket of products in a special category, and then write some PHP code that iterated over all the products in the category and put each one in the cart to buy.
×
×
  • Create New...