Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


Posts posted by ecartz

  1. Is this a module problem?
    Well, I don't get that error, so my first guess would be no. :)


    Anything is possible though. Have you tried using a different country? If it works for the US and fails for the UK, can you give me an example address? For the US, one that validates through PayPal is 1600 Pennsylvania Ave, Washington, District of Columbia, 20500. Other countries should have similar public addresses that can be tried, e.g. 10 Downing St in the UK.


    Does this happen both with accounts created during checkout and with existing accounts?


    To help with debugging this, I might turn off javascript in the browser and go through checkout. On the page that says that since you have javascript off, we can't redirect you automatically, do a view source. Somewhere in the HTML, you should have hidden inputs with country values. What are they?

  2. There is no reason why you can't customize the look of checkout_redirect; however, I would avoid putting links on that page. Thus, I would recommend against including the standard header, footer, and columns. Making it fixed width and centered would not be a problem. If the background images are getting cached properly, they shouldn't be a problem either. If they are not caching, they could slow down the page, which would be undesirable.

  3. small thing Matt in your order.php you've left off the closing ?>

    the same in english/checkout_process, checkout_login, virtual_login


    would actually seem you've done it on all your english files

    That's a Zend best practice: http://framework.zend.com/manual/en/coding...ding-style.html


    As those files are pure PHP, there's no point in them switching to HTML context, which is what the ?> does. Doing so gives rise to problems with headers already sent, as white space at the end of the file is interpreted as content rather than whitespace. Unfortunately, there's not much that can be done with the <?php at the beginning of the file, since PHP does not have a supported way of including files as PHP code rather than HTML (I suppose that one could hack something together with eval).

  4. The approach that I would take would be to go to includes/modules/product_listing.php, find the following code (around lines 131 - 134):

    		  case 'PRODUCT_LIST_BUY_NOW':
    		$lc_align = 'center';
    		$lc_text = '<a href="' . tep_href_link(basename($PHP_SELF), tep_get_all_get_params(array('action')) . 'action=buy_now&products_id=' . $listing['products_id']) . '">' . tep_image_button('button_buy_now.gif', IMAGE_BUTTON_BUY_NOW) . '</a> ';

    and replace it with something like

    		  case 'PRODUCT_LIST_BUY_NOW':
    		switch ($current_category_id) {
    		  case '37': $buy_now_button = tep_image_button('button_buy_now_37.gif', IMAGE_BUTTON_BUY_NOW);break;
    		  case '35': 
    		  case '33': 
    			$buy_now_button = tep_image_button('button_buy_now_3X.gif', IMAGE_BUTTON_BUY_NOW);break;
    		  default: $buy_now_button = tep_image_button('button_buy_now.gif', IMAGE_BUTTON_BUY_NOW);
    		$lc_align = 'center';
    		$lc_text = '<a href="' . tep_href_link(basename($PHP_SELF), tep_get_all_get_params(array('action')) . 'action=buy_now&products_id=' . $listing['products_id']) . '">' . $buy_now_button . '</a> ';

    This example would show one buy now button only on category 37; another buy now button on categories 33 and 35; and the original buy now button on everything else.

  5. You should only have one URL per page for Google purposes. I would recommend updating the XML. It looks like you could just change

    	function hrefLink($page, $parameters, $connection, $add_session_id) {
    	if ( defined('SEO_URLS') && SEO_URLS == 'true' || defined('SEO_ENABLED') && SEO_ENABLED == 'true' ) {
    		return tep_href_link($page, $parameters, $connection, $add_session_id);
    	} else {
    		return $this->base_url . $page . '?' . $parameters;
    } # end function


    	function hrefLink($page, $parameters, $connection, $add_session_id) {
    	return tep_href_link($page, $parameters, $connection, $add_session_id);
    } # end function

    and it would work.

  6. Line 71:

    'banner.jpg', (tep_not_null($header_tags_array[logo_text']) ?

    should be

    'banner.jpg', (tep_not_null($header_tags_array['logo_text']) ?

    Note the ' before logo_text.


    Also, a code editor with syntax highlighting would make problems like that easier to find. Free examples include Notepad++ and Eclipse.

  7. You'd have to install a different SEO URLs contribution. Note that the -c-34 is what tells it what category you are viewing. If you install a contribution that takes it out, then you either have to add all your categories to the .htaccess or you need to look up the category name in the database. It's simpler (and more efficient) to just leave it, and for SEO purposes, it is irrelevant.

  8. Try changing the .htaccess to

    RewriteRule ^(.*)-p-(.*).html$ product_info.php?products_id=$2&%{QUERY_STRING} [R]
    RewriteRule ^(.*)-c-(.*).html$ index.php?cPath=$2&%{QUERY_STRING} [R]
    RewriteRule ^(.*)-m-([0-9]+).html$ index.php?manufacturers_id=$2&%{QUERY_STRING} [R]
    RewriteRule ^(.*)-pi-([0-9]+).html$ popup_image.php?pID=$2&%{QUERY_STRING} [R]
    RewriteRule ^(.*)-t-([0-9]+).html$ articles.php?tPath=$2&%{QUERY_STRING} [R]
    RewriteRule ^(.*)-a-([0-9]+).html$ article_info.php?articles_id=$2&%{QUERY_STRING} [R]
    RewriteRule ^(.*)-pr-([0-9]+).html$ product_reviews.php?products_id=$2&%{QUERY_STRING} [R]
    RewriteRule ^(.*)-pri-([0-9]+).html$ product_reviews_info.php?products_id=$2&%{QUERY_STRING} [R]
    RewriteRule ^(.*)-i-([0-9]+).html$ information.php?info_id=$2&%{QUERY_STRING} [R]

    Backup first, as you will want to revert this later. The point is to find out to where it is rewriting your URLs.


    Another thing to check is that maybe you should have

    RewriteBase /

    instead of /catalog/

  9. The tep_href_link function should be defined in includes/functions/html_output.php


    That file should be included by includes/application_top.php which should be included by the page that you are trying to load. If all pages are not working (possibly with different errors), then it is likely either includes/functions/html_output.php or includes/application_top.php. If just the one page is not working, it might be a problem in that page.

  10. If the URLs were not working, then it might be a .htaccess issue, but if the links aren't SEO URLs, then it's a code or configuration issue. Try looking into includes/classes/seo.class.php or admin >> Configuration >> SEO URLs.


    Another option would be to try installing a different version of the contribution (either older or newer). Perhaps the one that is installed now has a bug in it.

  11. Hi Harald, this 'Sage Pay Merchant Account' - would I be right in saying this is within Sage Pay's own site rather than the osCommerce administration section?
    Not Harald, but I can answer this: yes, that's in the settings on the Sage Pay site. You are essentially giving it a whitelist of IPs that can process payments on your account. Apparently Sage Pay will reject payment requests from other IPs.


    When you sign up for a simulator account, they should send you a link to the simulator which you can use to change settings, etc.

  12. ... I believe my customer base feels more secure having the choice.
    But what about the choice is making them more secure? It's obviously not the reality of the data handling, because while PWA deletes the data from the customers table (when everything works), it leaves it in the orders table.


    Is it that they feel that creating the account is a barrier? Would it be enough to simply not label it creating an account? That's what I did in my latest add on. I create the account but without requiring a password. If the customers want to actually use the account, they need to "activate" it, which resets the password and emails it to them. That gives the customer the option of not activating the account if they are not going to use it again. I call it Purchase before Account functionality. Would that be enough to make your customers feel secure? Or is it something else?


    At one point, I was going to create the account on the checkout success page (and offer the customer a chance to pick a password), but I decided that that would not be robust (checkout_success is not a required page in the payment process). However, by that time, I already had working code that used the express checkout version of $sendto and $billto (i.e. arrays) to progress through the checkout. As such, a true Purchase without Account module could be written that never saves the customer information anywhere other than in the order. No dummy customers and address_book rows that get deleted later. Just session variables.


    I've also seen people talk about a faster checkout and avoiding extra steps. However, the registration only slows down the checkout if you let it. In my add on, I create a new checkout login page where there are two forms. In one form, the customer can login (just like in login.php; in fact, it posts to login.php). In the other form, the customer can enter shipping and contact information. If the customer uses the latter form, an account is created and they go to checkout_shipping.php. This saves two clicks from the standard osCommerce checkout (the click to go to the registration page and the click to leave the create account success page and go back to checkout) and one from Purchase without Account (the one where the customer chooses a guest checkout). The account gets created and it uses fewer steps than does Purchase without Account.

  13. Link to Checkout Redux: http://addons.oscommerce.com/info/7019


    This is a public Beta of an add on that rewrites the checkout process to do three things:


    1. Insert orders in the database before redirecting to external payment processors (e.g. PayPal).

    2. Shorten the checkout registration process by creating the account implicitly rather than explicitly.

    3. Accelerate the checkout process by skipping steps where the user was just clicking a continue button.


    The process goes somewhat like this: for users who are not logged in, they go to a checkout login page where they have the option of logging in or of entering a shipping address (billing address in the case of virtual products). If they enter a shipping address, it creates an account automatically, with a random password. The next step is to check if there is more than one shipping option; if there is, it will show the checkout shipping page and allow the customer to pick; if there is not, it will register the shipping method and skip to the payment page. On the payment page, it will again check if there is more than one option; if there is, it will let the customer pick; if there is not (or after the customer picks), it will go to the confirmation page.


    After the customer confirms, it goes to checkout_process (always) and inserts the order. If the payment method includes a redirect, it will then do a form post via javascript (for users who do not have javascript enabled, they will have to click a continue button). When payment completes and redirects back to checkout_process, the email gets sent unless the payment module has a process_notification variable set. In that case, it will wait to send the email until the notification is received by the processor. For customers who registered during this checkout, an additional section will be added to the email that explains how they can activate their accounts.


    If the customer cancels the transaction at the processor, the order will be marked cancelled and the products will be reloaded into the shopping cart. A store owner can browse these cancelled orders and optionally take actions to try to recover them (e.g. emailing the customer asking if there was a technical problem; offering a discount, etc.).


    For a store that only has one payment method and one shipping method, the normal effect of all this will be for the checkout to consist of a login step, a confirmation step, payment, and a notification step. For all customers, it removes the shipping and payment selection steps (if not needed). For new customers, it also removes the click to go to registering an account and the click to continue after registering the account. What was a minimum of seven clicks for a new customer is now down to just three (checkout, submit address, confirm) plus anything extra required by the payment processor.


    This add on includes a modified version of the PayPal Standard module that incorporates the notification method from the add on. Other payment modules with IPN style functionality would need to be modified to use the new method to take advantage of how this add on works. Fortunately, this consists mostly of deleting code from the payment module. The notification processor does need to be modified to include the emailing portion of the contribution, which is packaged into a module for reuse in that way.


    The package also includes a Google Analytics integration (to demonstrate the advantages of some of the checkout success changes; contrast with the osCommerce Google Analytics module upon which it is very loosely based), alternate files for use with the DHTML State Selection add on, and an example of how to integrate another add on that changes the checkout_process.php file: Gift Voucher (GV) and Discount Coupons (DC) for RC1, RC2, RC2a.


    Unfortunately, due to the completeness with which the add on changes checkout_process.php, it's not suitable for installation on modified stores (it can be done, but you really need to know what you are doing). The installation instructions require that you start with a clean osCommerce 2.2 RC2a store and copy over the existing files. Once you've done that, the installation instructions include information for integrating other add ons with the modified files, using the included integrations as examples.

  14. This contribution isn't really supported anymore. You might get better luck with Option Types v2 which is based on this contribution, along with the AJAX Attribute Manager. In particular, I believe that it includes image preview for logged in users. I probably should create an updated version of this contribution that points this out.


    You should be able to adjust quantity on the shopping cart page (in either contribution). You could also add one of the quantity update mods (on the product_info page) along with these contributions. They should be reasonably compatible.

  15. Since there doesn't seem to be a support thread for this contribution, posting one. The Admin Reports Count Reset contribution is at http://addons.oscommerce.com/info/2246


    Note that the contribution actually clears the values in the database. This affects the best sellers list as well as the admin reports. The contribution includes the ability to clear either products viewed or ordered for a single product or for all of the products at once. For this reason, it is best to backup the database before using. Changes can not be undone in the tool.


    This contribution also allows you to sort the report tables by count (ascending or descending) and product name (again ascending or descending). Further, it fixes a bug in the osCommerce distribution where the row number would show 01 to MAX_SEARCH_RESULTS on each page. The rows will now be numbered correctly, starting at MAX_SEARCH_RESULTS + 1 on the second page. For example, if you have osCommerce configured with MAX_SEARCH_RESULTS of 20, it will show 01 to 20 on the first page, 21 to 40 on the second page, 41 to 60 on the third page, etc.


    The current version of the contribution (1.5) should be completely compatible with osCommerce 2.2 RC2a and with register_globals set either on or off.

  16. Not sure what this has to do with payment modules, and this is more a QuickBooks thing than an osCommerce thing. You might get better help on their forums. However, as best I can tell, the owner ID is something that you make up. It's only significance is that it be different from the owner IDs that others use and that your application always passes the same one. It's specific to you, so your owner ID should be different from someone else's owner ID, even if they are also integrating with osCommerce (otherwise, you could read each other's data). If you think of it as a password with a special format, that's probably close enough.


    I don't know about the appropriateness of posting a link, but googling for "generate GUID online" returns results.


    The whole snippet from the Quickbooks Web Connector Programmer's Guide:

    This is a GUID that represents your application or suite of applications, if your application needs to store private data in the company file for one reason or another. One of the most common uses is to check (via a QuickBooks SDK CompanyQuery request) whether you have communicated with this company file before, and possibly some data about that communication.


    You should generate one GUID per application only and not per application version or per QWC file!


    This private data will be visible to any application that knows the OwnerID.


    (See the QB SDK Programmer’s Guide for more information on data extensions and OwnerID.)

  17. alright i narrowed down the problem being with Ultimate SEO YMM.

    When using Ultimate SEO with YMM it's giving the redirect error.

    I think that there are two options (short of disabling Ultimate SEO URLs). The no code option is to turn off W3C URLs in Ultimate SEO.


    The option that I prefer is to change tep_redirect (in includes/functions/general.php) to

    // Redirect to another page or site
     function tep_redirect($url) {
    $url = str_replace('&', '&', $url);
    if ( (strstr($url, "\n") != false) || (strstr($url, "\r") != false) ) { 
      tep_redirect(tep_href_link(FILENAME_DEFAULT, '', 'NONSSL', false));
    if ( (ENABLE_SSL == true) && (getenv('HTTPS') == 'on') ) { // We are loading an SSL page
      if (substr($url, 0, strlen(HTTP_SERVER)) == HTTP_SERVER) { // NONSSL url
    	$url = HTTPS_SERVER . substr($url, strlen(HTTP_SERVER)); // Change it to SSL
    header('Location: ' . $url);

    However, I haven't tested that, so it may need more work. The next thing that I would try if that doesn't work would be changing the str_replace line to

    $url = htmlspecialchars_decode($url);

  18. 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.

  19. there's no real "quick fix" for either problem...
    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).

  20. 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.