ecartz

Googling for "eregi deprecated" finds this thread among other results. And that thread links to quick fix for eregi deprecated warning.

Set "Use Search-Engine Safe URLs (still in development)" to false in admin >> Configuration >> My Store. Make sure that "Enable SEO URLs" is set to true in admin >> Configuration >> SEO URLs. You are currently not using Ultimate SEO URLs; you are using the SEF URLs that come with osCommerce and are useless. They are meant to solve a problem that search engines had in 2002 but have long since fixed.

The quick fix for a store owner is to be careful about how the order in which they add option values and add an explicit order by in the value query, e.g something like $products_options_query = tep_db_query("select pov.products_options_values_id, pov.products_options_values_name, pa.options_values_price, pa.price_prefix from " . TABLE_PRODUCTS_ATTRIBUTES . " pa, " . TABLE_PRODUCTS_OPTIONS_VALUES . " pov where pa.products_id = '" . (int)$HTTP_GET_VARS['products_id'] . "' and pa.options_id = '" . (int)$ProdOpt_ID . "' and pa.options_values_id = pov.products_options_values_id and pov.language_id = '" . (int)$languages_id . "' order by pov.products_options_values_id"); If the current behavior is to select the first value from the menu, then the desired value should be added first. Obviously, better fixes in the long term would require adding a sort order column that can be changed, as exists in other contributions and adding a "set as default" status for attributes (to allow for values other than the first to be selected).

There are three basic patterns: 1. The store collects the credit card info and sends it to the processor. An example is Authorize.net AIM. 2. The store redirects to the payment processor (passing the customer and order information in the data built in the process_button function), who collects the information and posts back. The payment modules' before_process function then evaluates the processors response and takes an appropriate action (e.g. redirect to checkout_payment if the card is declined). An example is Authorize.net SIM. 3. The store redirects to the payment processor, who collects the information and posts back. The payment processor also sends a payment notification message separately, which the store processes and uses to update the order status. An example is PayPal Standard in RC2a (the older one in MS2 worked like Authorize.net SIM). It sounds like you have #2, but you could have #3. You'd have to check the processor's developer documentation to be sure.

You could try looking in includes/classes for a file that starts pad_ and see if the HTML is in there.

This add-on adds a product listing to your front page. It is suitable for small stores, where the complete product list can fit on the front page. It shows all the products from all categories and manufacturers. It's a small mod, only one edit to make in each of two files (one of which is a language file, so you may need to make it multiple times). Contribution: http://addons.oscommerce.com/info/6996

It's not really a border per se. See changing the width of the pseudo border around infoBoxes. Note that depending on what you want to accomplish, the simplest thing might be to set it to 0 and then add a CSS border that you can style.

It doesn't look like the file is uploaded. Look at http://www.wickedink.se/catalog/stylesheet.css -- it still has the old code with the comment and the 333333.

Taking the comment off the line would mean changing it to .infoBox { background: #f2f2f2; /* background: url(images/infoboxbg.jpg); */ border: none; padding : 3px; } If it's inside the comment tags, it might as well not exist.

admin/includes/configure.php It sounds like it has define('HTTP_CATALOG_SERVER', 'http://'); when it should have define('HTTP_CATALOG_SERVER', 'http://shop.98331gear.com');

No, the colon is where it is supposed to be. That code would work if STS used it. A quick look at STS suggests that changing $myaccountlogoff | $cartcontents | $checkout in includes/sts_templates/full/sts_template.html (replace full with your template name; and make the same change to all the other templates that you use that show the header) to $myaccountlogoff | $cartcontents $checkout and changing $sts->template['checkout'] = '<a href=' . tep_href_link(FILENAME_CHECKOUT_SHIPPING, '', 'SSL') . ' class="headerNavigation">' . HEADER_TITLE_CHECKOUT . '</a>'; in includes/modules/sts_inc/general.php to if ( $cart->count_contents() > 0 ) { $sts->template['checkout'] = '| <a href=' . tep_href_link(FILENAME_CHECKOUT_SHIPPING, '', 'SSL') . ' class="headerNavigation">' . HEADER_TITLE_CHECKOUT . '</a>'; } else { $sts->template['checkout'] = ''; } would probably do it.

What actually happens when you place an order? When you get back from Linkpoint, where do you go next? Also, your COOKIE settings seem flawed. Even when I allow cookies, I still get an osCsid in the URL. You may want to post the relevant lines from your configure.php file (the ones with HTTP in them).

I generally start with an existing module for a processor that works the same way as your new processor does. There are examples with the osCommerce distribution. Then I look at what needs to be different and modify it. In general, you need to implement process_button.php if you are POSTing to an external processor and they will redirect back to osCommerce after processing. If you are calling the processor via curl or other backend interface, you do this in the before_process function. The selection function is where you add any form inputs that you need the user to enter. The install function is where you run the initial configuration SQL, and you read the configuration in the constructor. You can get a minimalist example by looking at the COD module. Since it collects no information and does no processing, it implements as little of the API as is possible. However, it still must define all the needed functions. Since it doesn't do anything, it doesn't define any helper functions that are not required.

Make sure that your confirmation URL in Linkpoint is checkout_process.php If you didn't before, add the revised text to checkout_payment.php: <!-- body_text //--> <td width="100%" valign="top"><?php echo tep_draw_form('checkout_payment', tep_href_link(FILENAME_CHECKOUT_CONFIRMATION, '', 'SSL', false), 'post', 'onsubmit="return check_form();"'); echo tep_hide_session_id(); ?><table border="0" width="100%" cellspacing="0" cellpadding="0"> It is possible that this matters. Make sure that you checked all 4 boxes for: Url is a CGI Script and Automatically display Confirmation Page after the Connect receipt page

Try searching for individual shipping. Or Google for setup shipping price for each product.

There is a Babelfish translation infobox contribution. Also, a Quick Translation Facility contribution. The latter is especially useful to this discussion in that it explains how it should only be used in limited ways. For example, to include a product before the real translation is completed. Automated translation is not a substitute for actual copy written directly in the appropriate language. One problem that arises is homonyms. Homonyms are words that are spelled the same but have different meanings. The automated translation software has to guess which meaning is intended. A human translator with knowledge of the product will know. Here are two automated translations: English to Russian to English in Babel fish: English to Turkish to English in Google translate: Note that neither returns to your original words. Further, the words that we have now don't always make sense. What is "in proportion to it comes from the box" or "per the language of money"? In my opinion, it is better for a store owner to admit a lack of knowledge in a language than to try to pretend to speak a language. Let the customer use the auto translation software. That way, instead of blaming the store for not speaking the language properly, the customers will blame the translation software. There is an art to writing good marketing copy. What works in one language is unlikely to carry over to another language. Better than translating is to write fresh copy for each language, appealing to the social cues specific to that culture. That's why it's great that osC 3 will support localized languages, e.g. en_GB, en_US, and en_AU. Beyond the simple spelling differences, each country has its own culture which colors (or colours for non-en_US readers) its text. For example, the Fourth of July and Thanksgiving do not have the same meaning in the other two countries as they do in the US. Promotions based on those holidays would fall flat outside the US. It's great that auto-translating works for you. However, it wouldn't work for many store owners. I've seen far more complaints in the other direction, where trying to serve both (for example) US and UK customers fails because the marketing copy doesn't work right. Many store owners feel the need for more control over their marketing copy, not less. Not to mention that osCommerce supports more than the twelve languages in Babel Fish. Not out of the box, but would it really address your issue if osCommerce shipped with more languages? Most store owners only use one anyway. Deleting the other languages is one of the first steps that many stores take, about the same time as deleting unused countries and currencies.

Your host's server should have more than 16 MB of RAM. You would be hitting the PHP memory_limit for a single request. The host could turn up the memory_limit (possibly just for you) but may not want to do so. You could switch to a different shared host with a higher memory_limit setting in php.ini, which would be cheaper than a dedicated server.

Around lines 110-111 of includes/modules/shipping/zones.php, change the 1 in // CUSTOMIZE THIS SETTING FOR THE NUMBER OF ZONES NEEDED $this->num_zones = 1; to be the appropriate number for your store. I haven't used this module recently, so I don't know if that's the only change that needs made or not.

You can set the weight of a product when adding or editing it. It's on the same page where you enter the name, description, and price. Zone rates shipping allows you to set different shipping tables (by weight) for the various regions. You may have to edit code to make it support more than one region. It's not completely configurable.

There is at least one Purchase Order payment module for osCommerce. Is that what you mean?

PayPal is saying that IPN is broken and they are going to fix it. It's not an API change. Something happened that PayPal is broken and needs fixed.

I think that you could do this by installing table rate shipping with a table of 20:3.00,10000:0.00 for your regular option and flat rate shipping for your fast option.

However, the function does not exist in the file general.php. In a normal install, it would be in html_output.php. I didn't add the function to the file manually. I had a fresh install. I copied the new files over the existing files. As things stand, copying files with RC2a is broken and won't work. Further, even if someone did follow the instructions, they would still break things, because they would look in general.php, find that the function is not there, add it to general.php, and then the copy in html_output.php would break things. The instructions should say, =================================================================== Add the following to admin/includes/function/html_output.php before the last ?> IF it does not already exist in that file. //// // Hide form elements function tep_hide_session_id() { $string = ''; if (defined('SID') && tep_not_null(SID)) { $string = tep_draw_hidden_field(tep_session_name(), tep_session_id()); } return $string; } rather than general.php

I just installed the latest version of the contribution, and there are two things that I would consider bugs. The first (and more serious) is that in admin/includes/functions/general.php, a tep_hide_session_id() function is added, but in a clean RC2a (just downloaded today), that function is already defined in admin/includes/functions/html_output.php. This causes an error about duplicate function definitions that breaks admin. Perhaps this function should only be added to MS2? Possibly in html_output.php rather than general.php (in case someone wants to upgrade MS2 to RC2a later). The second, less serious, perhaps purely pedantic, is that the following code (in the instructions, product_info.php, and index.php; for the RC2 files -- I didn't look at the MS2 files) should be <?php /*** Begin Header Tags SEO ***/ if ( file_exists(DIR_WS_INCLUDES . 'header_tags.php') ) { require(DIR_WS_INCLUDES . 'header_tags.php'); } else { ?> <meta http-equiv="Content-Type" content="text/html; charset=<?php echo CHARSET; ?>"> <title><?php echo TITLE; ?></title> <?php } /*** End Header Tags SEO ***/ ?> rather than <?php /*** Begin Header Tags SEO ***/ if ( file_exists(DIR_WS_INCLUDES . 'header_tags.php') ) { require(DIR_WS_INCLUDES . 'header_tags.php'); } else { ?> <title><?php echo TITLE; ?></title> <?php } /*** End Header Tags SEO ***/ ?> This will obviously not cause an issue for anyone who has header_tags.php installed correctly. However, if we're only worrying about the correct install case, why not make it simpler and just use (as a replacement for the above code) <?php require(DIR_WS_INCLUDES . 'header_tags.php'); ?> which is just as good in the correct install case and will throw an error for certain incorrect installs (rather than producing incorrect output).

The original code to display the image on the product info page looks like this: <script language="javascript"><!-- document.write('<?php echo '<a href="java script:popupWindow(\\\'' . tep_href_link(FILENAME_POPUP_IMAGE, 'pID=' . $product_info['products_id']) . '\\\')">' . tep_image(DIR_WS_IMAGES . $product_info['products_image'], addslashes($product_info['products_name']), SMALL_IMAGE_WIDTH, SMALL_IMAGE_HEIGHT, 'hspace="5" vspace="5"') . '<br>' . TEXT_CLICK_TO_ENLARGE . '</a>'; ?>'); //--></script> <noscript> <?php echo '<a href="' . tep_href_link(DIR_WS_IMAGES . $product_info['products_image']) . '" target="_blank">' . tep_image(DIR_WS_IMAGES . $product_info['products_image'], $product_info['products_name'], SMALL_IMAGE_WIDTH, SMALL_IMAGE_HEIGHT, 'hspace="5" vspace="5"') . '<br>' . TEXT_CLICK_TO_ENLARGE . '</a>'; ?> </noscript> The way that it works is that if users have javascript enabled in their browsers, it uses the first part in the script tags. If they do not have javascript running, it uses the second part (inside the noscript tags). So if you first try it by adding the code inside in the noscript tags, it won't work as javascript enabled browsers won't see it. If you take out the noscript tags but leave the script block, then the image will show once for the script block (if javascript is enabled) and once for your code. If you replace both the script and the noscript blocks, it should have the effect that you want. However, it won't show a popup image if the browser does not have javascript enabled.