Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Jim Lekas

Pioneers
  • Posts

    13
  • Joined

  • Last visited

Everything posted by Jim Lekas

  1. Changing edit_orders to update the quantity in inventory will take a little work. It appears that pattern established in checkout_process can be followed, but the quantity adjustment will probably have to compare the "after" order with a "before" order to find out what changes were made. It would be helpful to consolidate the quantities for each unique product id when it occurs on two order lines (if the product attributes mechansims don't interfere.) Unlike checkout_process, which only reduces inventory quantities, edit_orders will have to increase inventory quantities when an order quantity is reduced or when an order or order line is deleted. The inventory adjustments of checkout_process and edit_orders probably should be combined in an inventory module, and the inventory probably should be kept in a record separate from the products record.
  2. Hi akkinmore. When you say "When you add product to the order the quantity is not updated", do you mean that you press the "Add Product" button to add more of a product already on the order? In that case you probably see a new line item for the added quantity. Probably identical items should be merged, but it is easy enough just to change the quantity field if you are adding more of something already on the order. Perhaps you are altering the quantity on a line, but not seeing the order price change? In that case, maybe you need to scroll to the bottom of the order edit page and press the "Update" button? Or are you saying that it worked before you introduced my changes? In that case I will be grateful for an example or other detail to rectify the changes as soon as possible. -- Jim
  3. Regarding akkinmore's question about negative option prices being registered as positive prices: The problem appears to be that products_attributes table carries the sign (+ or -) in a separate "price_prefix" field, but edit_orders doesn't make use of it. To take the price_prefix into account, I suggest the following two changes. WARNING: These changes have been only lightly tested. Back up your file. At about line 366 of edit_orders.php (v 1.3), replace extract($row, EXTR_PREFIX_ALL, "opt"); $AddedOptionsPrice += $opt_options_values_price; $option_value_details[$option_id][$option_value_id] = array ("options_values_price" => $opt_options_values_price); with extract($row, EXTR_PREFIX_ALL, "opt"); if ($opt_price_prefix == '+') { $AddedOptionsPrice += $opt_options_values_price; } else { $AddedOptionsPrice -= $opt_options_values_price; } $option_value_details[$option_id][$option_value_id] = array ( "options_values_price" => $opt_options_values_price, "price_prefix" => $opt_price_prefix); and at about line 407 of edit_orders.php, replace price_prefix = '+';"; with price_prefix = '" . $option_value_details[$option_id][$option_value_id]["price_prefix"] . "';";
  4. Hi Morb. I'm happy to hear that you got it working. That is one strange error. When you have time you might want to call in an exorcist.
  5. Morb, The second SQL statement -- at the bottom of my previous message -- corrects the problems I see, assuming that every product has a product description, every category has a category description, and the program doesn't need the product results repeated for each language in the system. From my reading of the code these assumptions are correct, but I thought I'd better check with people who know the system. You can just replace the first query from my earlier message with the second to correct the problems. Note that I presented the first query in a multi-line format for easier reading, but otherwise it is identical to the query in your edit_orders.php file. In case you were wondering, the original SQL query had a minor typographical error (x.categories_name=ptc.categories_name) which caused it to expect a nonexistent product_name field in the table specified by TABLE_PRODUCTS_TO_CATEGORIES. Changing "ptc" to "cd" in that one expression will cause the Add Product feature to start working. However, by leaving the language constraint out, the query retrieves a separate result for each langauge. E.g. products_id 1, categories_id 1, english categories_name products_id 1, categories_id 1, german categories_name products_id 1, categories_id 1, spanish categories_name Thus you get three times the number of rows you might expect from the query. (You only see one copy on the Order Edit display because the ensuing loop in edit_orders.php writes all of the product_name fields into the same array variable, so the last language wins.) Furthermore, the second join on TABLE_CATEGORIES_DESCRIPTION will duplicate each result for each duplicated category name. For example, I have a category with a name in English, but blank names in German and Spanish. The "extra" join matches on the blank names, which produces two more copies of the result, increasing the total to five times the number of products. Normally the category names would vary according to the language, but I still don't see how this extra join is helpful. Using an outer join (LEFT JOIN) causes a record containing only null fields to be provided where no record from the right hand side matches a given record from the left hand side. For instance, if a products_description record were missing, the result for (products_id, products_name) might be (1, NULL). Had an ordinary join been used, no row would have been returned because of the missing products_description record. I think the outer join is more expensive, and it suggests to the reader that an empty record might normally occur on the right side. The latter is technically true (I created a product outside all categories), but it doesn't seem to fit the way the system works. In summary, by adding the language constraint I reduced the number or records returned from five per product to one per product. Dropping the "extra" join on categories_description appears to eliminate superfluous work, but I might be missing something clever there. Replacing outer joins with ordinary joins should be more efficient, and probably reflects the semantics of the system better.
  6. Thanks to the authors for the useful OrderEditor v. 1.3. I'm just evaluation osCommerce to see if I can make it work for my small web site, so I don't know too much about it yet. The Add Product SQL in edit_orders.php, v. 1.3, line 903 contains an error which prevents Add Product from working: //##################################### // Get List of All Products //##################################### $result = tep_db_query("SELECT products_name, p.products_id, ptc.categories_name, ptc.categories_id" . " FROM " . TABLE_PRODUCTS . " p " . " LEFT JOIN " . TABLE_PRODUCTS_DESCRIPTION . " pd ON pd.products_id=p.products_id" . " LEFT JOIN " . TABLE_PRODUCTS_TO_CATEGORIES . " ptc ON ptc.products_id=p.products_id" . " LEFT JOIN " . TABLE_CATEGORIES_DESCRIPTION . " cd ON cd.categories_id=ptc.categories_id" . " LEFT JOIN " . TABLE_CATEGORIES_DESCRIPTION . " x ON x.categories_name=ptc.categories_name" . " ORDER BY categories_id"); The immediate problem can be fixed by changing "ptc.categories_name" to "cd.categories_name". However, this query raises some questions. 1. Why is there a join between x.categories_name and ptc.categories_name (cd.categories_name) at all? 2. Why aren't pd and cd constrained as to language (language_id = $languages_id)? 3. Is it permitted to have a product with no name? If not, why use an outer join between pd.products_id and p.products_id? 4. Is it permitted to have a category with no name? If not, why use an outer join between cd.categories_id and ptc.categories_id? 5. Is it permitted to have a product not in any category? (It can be done, but the product can't be reached on the order page, etc.) If not, then why use an outer join between p.products_id and ptc.products_id? Does anyone know where to find more information about the intended semantics of the database schema? I have the tep_database-pr2.2-CVS.pdf schema, for which I am very grateful, but it doesn't say just how the category-product intersection table can be used. The following query produces similar results, with far fewer rows to be filtered by the ensuing loop. $result = tep_db_query("SELECT products_name, p.products_id, cd.categories_name, ptc.categories_id" . " FROM " . TABLE_PRODUCTS . " p, " . TABLE_PRODUCTS_DESCRIPTION . " pd, " . TABLE_PRODUCTS_TO_CATEGORIES . " ptc, " . TABLE_CATEGORIES_DESCRIPTION . " cd " . " WHERE pd.products_id = p.products_id " . " AND ptc.products_id = p.products_id " . " AND cd.categories_id = ptc.categories_id " . " AND cd.language_id = '" . (int)$languages_id . "'" . " AND pd.language_id = '" . (int)$languages_id . "'" . " ORDER BY ptc.categories_id, p.products_id");
×
×
  • Create New...