wdepot

I'm very glad to see that osCommerce 4 is apparently going to include size information to use on products for shipping purposes since basically all carriers now charge dimensional weight if a package is large but light. I assume that there will be some setup for available boxes to use for shipping to go with this. I would interested in knowing if osCommerce 4 will allow for single products that come in multiple packages for shipping purposes, like the split products portion of the dimensional weight contribution that is available for osCommerce 2.3.x. I would also hope that the packaging routine for osCommerce 4 doesn't do like the one in the aforementioned dimensional weight contribution and add products to a box based solely on the calculated remaining volume. We have had more than one instance of our 2.3.4 packager using a particular size box for a rate quote that the products won't all physically fit in to because of the dimensions of the products even though the total product volume is less than the volume of the box. Each product is checked to be sure it will fit in the box individually, but it doesn't check to see if they will fit in the box together with the other products based on their dimensions.

1. filenames.php is active through all versions of osCommerce 2.3. Maybe in 2.4 they are removing it but the contribution wasn't updated for 2.4 but for 2.3 2. I thought I had updated the instructions to say that the htaccess (or httpd.conf) needed to point to the actual location of the http_error.php file. 3. The pop up search comes directly from the advanced_search.php file since the search portion of the error document was copied directly from the advanced_search.php file that came with osCommerce 2.3.4. Download a copy of osCommerce 2.3.4 and use the pop up search file from that if your version is missing the file.

Yes, the new function should be added to catalog/includes/functions/general.php as you suspected.

I've just posted an bug fix to the Extra Product Fields 2.3 contribution at http://addons.oscommerce.com/info/6856 which fixes a failure to hide a restricting field dropdown if that field is set as not applying to the category being browsed.

I've just posted an update to the Extra Product Fields contribution at http://addons.oscommerce.com/info/6856 which adds the ability to restrict extra fields to being available only to products which exist in certain categories.

Bundled Products version 2.0 has been posted to the contribs. New features include: --Changed database definitions of the fields so that the type of the ids in the product_bundles table is the same as the products_id in the products table. Also changed the products_bundles definition from tinytext to enumerated to save database space. --Replaced hardcoded language in categories.php with defined language. --Added capability of properly duplicating product bundles in categories.php. --Added instruction for properly deleting a bundle. --Added preview of bundle information in categories.php to match the one in product_info.php. --If the same product is added to a bundle twice the quantities are combined so that only one line per subproduct exists in the product_bundles table which enables PRIMARY indexing on this table. --Added headings for the Bundled products columns during edit, hid the fields for the subproduct ids, and disabled entry in the subproduct name fields to prevent possible errors that might be caused by tampering with these fields during entry/editing. --Changed code that only allowed bundles to be nested one level to allow nesting to any level. --Added code to prevent adding to a bundle another bundle that, directly or via nested bundles, contains the bundle being edited. --Added code for checking bundle stock that was missing from checkout_payment.php. --Added code to verify that a product marked as a bundle actually is one. If a product is marked as a bundle during editing in categories.php but no products are added to it the bundle will be changed to "no" while saving the product in the database. --Bundle weight is calculated automatically from the products it contains when saving the bundle to the database. --Added code for the packaging routines added to the shopping cart class by the UPSXML contribution so that information for bundle products comes from the products contained in the bundle.

It sounds to me like you just need to create entirely new products instead. Use the Copyto/Duplicate function if most of the information will remain the same and you could save yourself some typing.

I've just posted an update to the Extra Product Fields contribution at http://addons.oscommerce.com/info/6856 which fixes a small bug during field creation where a question related only to text fields was being required during the creation of a list type field. I also added an install instruction so that existing Extra Fields are properly handled if a language is added or deleted using Admin/Localization/Languages.

I suspect you may be running into a permissions problem here. In order to create a thumbnail image the product_thumbnails directory and every product image directory that it contains must be able to be read AND written by your web site. Assuming you were previously using osCommerce, set the permissions the same as you had on the original catalog/images folder. This holds true for all of the new folders for this contribution. The same problem is probably causing the problem with deleting an image. Both the image file itself AND the directory that contains it must be writable by your web site in order for the prod-img-manager program to be able to delete the file. Normally the directory permissions should be set to the minimum required to allow your admin site to write to the image directories. If your site directories are owned by PHP you should be able to set the directory permissions to 755. If PHP is in the same group as the owner of your site directories then permissions would have to be 775. And if PHP is merely considered a guest user of your site directories then you would have to set permissions on all of the image directories to 777. The default permissions on new image files uploaded by osCommerce is 777 so it is probably a directory permission problem that is causing the delete to fail.

The Extra Product Fields contribution version 2 and higher allows you to easily create fields that use radio buttons, drop down lists or check boxes. It even includes a utility to convert data from Product Extra Fields to Extra Product Fields.

You missed installing the code at the beginning of index.php that loads the $epf array with the extra field information. Since $epf doesn't get defined as an array the foreach ($epf as $e) creates an error.

Version 2.2 of the contribution addresses this request.

I haven't heard of the customer extra fields contribution. If the conflicting file names are simply the administration maintenance files like extra_fields.php you should be able to get by with renaming the file (don't forget to rename it's language file the same) and adjusting the define in filenames.php to match. If they use the same defined name (FILENAME_EXTRA_FIELDS) then things will be much more complicated and you would need to edit one of the contributions to use a totally new defined name. If the conflict is a database table (doubtful) then rename one table and adjust the define in database_tables.php. If there is a conflict in the defined name (TABLE_EXTRA_FIELDS) then once again you would need to totally edit one contribution. Best of luck to you.