Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


Posts posted by ecartz

  1. 39 minutes ago, maxmind.jason said:

    Dear nrlatsha,

    Please get in touch with us at MaxMind (info at maxmind.com) if you would be interested in collaborating on updating your plugin for more advanced minFraud features. We'd be happy to work with you.



    @maxmind.jason, it looks like @nrlatsha last posted to this thread more than four years ago and last visited the forums three years ago.  So I'm not sure that your message is likely to get read by its intended recipient.  If you wanted to take over this module more directly and post a more up-to-date version, that would be fine. 

  2. 10 minutes ago, raiwa said:

    It's not the Apps Area, it's the uploaders 😉

    That's what I was saying.  The Apps area is not designed for the way that people have been uploading. 

    There are changes that could be made to the apps area that would make it better, even *with* the way that people try to use it.  For example, a simple fix would be to allow people to mark uploads as incremental and offer a filter based on that.  Of course, then we'd need a fix for people who pick the wrong one.  E.g. voting on such tags. 

  3. @LeeFoster, if you get this working consistently, it would be helpful if you could upload a new package with all the changes/instructions.  The hardest part about fixing this was finding a download that had the file!  The Apps area is not really designed to support incremental updates. 

    It's also not clear to me what changes are necessary in general and what were specific to someone's store. 

  4. 1 hour ago, LeeFoster said:

    I've just installed this on Phoenix and for the most part it works however if I have no Stores set to pick up from I get the below errors.

    In includes/modules/shipping/multipickup.php, around line 61, find

          while ($store = tep_db_fetch_array($qstores)) {

    and change to

          $this->quotes['methods'] = array();
          while ($store = tep_db_fetch_array($qstores)) {

    One line added.  No existing lines changed. 

  5. To answer the last question (however belatedly), it costs nothing to offer Amazon Pay on your website.  If someone uses it, Amazon charges transaction fees.  $.30 per transaction plus 2.9% of the transaction amount.  There may be other fees as well in certain circumstances.  E.g. 3.9% for cross-border transactions and $20 for a chargeback dispute. 

    Source:  https://pay.amazon.com/help/201212280

  6. It is working only when language is en.
    It's not clear to me why the language would make a difference. None of the new SQL queries are language dependent. Also, if I try it on my test site, it works (at least in Spanish and German).


    Perhaps the problem would be more obvious if you posted a link to the page that is not working?

  7. But, if they did decide to come back and buy more, I want to give them a chance of buying something else without giving them an error message that the email they would like to use is already in the system.
    The relevant section of code is
            if ($check_email['total'] > 0) {
             $error = true;
             $email_exists = true;
             $messageStack->add('checkout_address', sprintf(ENTRY_EMAIL_ADDRESS_EXISTS_ERROR, tep_href_link(FILENAME_PASSWORD_FORGOTTEN, '', 'SSL')));

    However, I don't know that there is a simple fix that preserves the advantages of the current system. One possibility would be to delete the previous row or change the email address in it so that the new row could be added. That's what the Purchase without Account contribution does. E.g. something like

            if ($check_email['total'] > 0) {
             tep_db_query("delete from " . TABLE_CUSTOMERS . " where customers_email_address = '" . tep_db_input($email_address) . "'");

    Note: I haven't tested this in any way.

  8. For 1, you would change

    // charset for web pages and emails
    define('CHARSET', 'iso-8859-1');

    to the appropriate charset in includes/languages/russian.php (or whatever language). Russian currently looks correct on your site, appearing in KOI-8. Maybe you fixed this. You also might need to make the same change in the admin languages file.


    For 2, if you were using the original template, the navigation would look like

        <td align="right" class="headerNavigation"><?php if (tep_session_is_registered('customer_id')) { ?><a href="<?php echo tep_href_link(FILENAME_LOGOFF, '', 'SSL'); ?>" class="headerNavigation"><?php echo HEADER_TITLE_LOGOFF; ?></a>  |  <?php } ?><a href="<?php echo tep_href_link(FILENAME_ACCOUNT, '', 'SSL'); ?>" class="headerNavigation"><?php echo HEADER_TITLE_MY_ACCOUNT; ?></a>  |  <a href="<?php echo tep_href_link(FILENAME_SHOPPING_CART); ?>" class="headerNavigation"><?php echo HEADER_TITLE_CART_CONTENTS; ?></a>  |  <a href="<?php echo tep_href_link(FILENAME_CHECKOUT_SHIPPING, '', 'SSL'); ?>" class="headerNavigation"><?php echo HEADER_TITLE_CHECKOUT; ?></a>   </td>

    and would be localizable. If your template does not do this, then you would need to change it so that it does. It would be hard to explain further without seeing the code that your template uses to display the navigation, but the idea is that you should replace hard coded strings like Home with code like

    <?php echo HEADER_TITLE_TOP; ?>

  9. In admin >> Configuration >> My Store, there should be an option for "Template Switching Allowed". Set that to true, and the template switcher should appear at the top of the page in the included templates. If you need to add it to a new template, it's the following code:

    // include template switcher in every template
    if ( bts_select('common', 'common_top.php') ) include (bts_select('common', 'common_top.php')); // BTSv1.5

  10. Are you using an option types contribution? The installation should show you where you need to make changes to pass a date rather than a MySQL ID. The simplest thing would be to install something like Option Types v2 and then use the text passing capability to pass the date value (rather than try to pass a MySQL date value). Date would simply be a new option type in that scenario, a new case in various switch statements.

  11. I see two main possibilities. One is that someone already tried to install the Bundled Products add-on. In that case, you just need to verify that the changes were made correctly.


    The second possibility would be that you are trying to use two installation methods at the same time. In one installation method, you upload the files that come with the contribution, writing over the existing files (which is why it is a good idea to do a site backup before doing this). That method is only meant to be used on new stores, where the files are unchanged from their original state. In the second installation method, you follow the instructions that tell you to find code and make modifications. It sort of sounds like you have uploaded the contribution files and are trying to modify the files that you uploaded. In this case also, you just need to verify that the code is there and proceed.


    Things are further complicated by the fact that in some of the files in the contribution, changes are made twice.


    Also, the contribution is not fully internationalized, so if you want to use it in a language other than English, you may need to manually edit some of the code files.

  12. Someone would have to modify your store so that STS knew to add the javascript on the appropriate pages. A possible solution might be to change

    <!-- body_text_eof //-->


        </table></form><?php require('includes/form_check.js.php'); ?></td>
    <!-- body_text_eof //-->

    and eliminate the other call to form_check. I don't have STS installed, so I can't test it. Or troubleshoot it for that matter.

  13. 1054 - Unknown column 's.public_flag' in 'where clause'
    That's the error that you get when you are using a pre-RC2a database with RC2a code. You should either update your database to RC2a or use an older version of the contribution.


    There is a contribution from Jan Zonjee for updating to RC2a. I haven't used it, but I would expect it to cover this issue.

  14. There already is an rss feed linked to on the contributions page:
    When I read her post, I thought that she was asking for multiple RSS feeds, one per contribution, so that it would work more like Contribution Tracker does.


    The main RSS feed is noisy, telling you about many contributions that don't matter to you. A more targeted feed or feeds would allow you to watch just the contributions that you are actually using. The current feed is good for finding new contributions to install (albeit with a high noise to signal ratio), but the desire is for updating currently installed contributions with the latest bugfixes and security patches.

  15. I'll leave your other questions to Mark or someone else in the know, but I can tell you that the issue tracker (also called the bug reporter) is at http://svn.oscommerce.com/jira/secure/Dashboard.jspa


    More specifically, 3.0 Alpha 5: http://svn.oscommerce.com/jira/secure/Issu...orter/order=ASC


    I believe that you would be looking for bugs that are reported against alpha 5 but are not assigned a fix version. Or for code fixes that are assigned a fix version but are not assigned a fixer.


    The issue tracker does have a place to attach a screenshot.

  16. It's not just that you don't need it. It's actively harmful to put a ?> in a pure PHP file that might have headers sent after it is included. The effect is to take you out of PHP context and put you into HTML context. However, you don't want to produce output while in HTML context. as it will then break any redirects or other HTTP headers that get sent after that. It's more robust to not use the ?> and end the file in PHP context. You can see this discussed more in the Zend Coding Standards, which prohibit the use of ?> in a pure PHP file (i.e. one that does not produce HTML output).

  17. modules/checkout_notification.php and ext/modules/payment/paypal/standard_ipn.php send emails. If you are using the PayPal module that came with the contribution, the order email should come from the IPN module in ext. Are the order statuses updating? You should see a Preparing status and then a Pending status (or whatever your defaults are).


    In ext/modules/payment/paypal/standard_ipn.php there is a line that says

      $send_debug_email = false;

    You could try changing it to true to see if it tells you anything useful. Note that it requires that the debug email to be set in admin >> Modules >> Payment, under the settings for the paypal standard module.

  18. For others who might encounter the same problem, it looks like illegal template directory is caused by

      if ((ereg('^[[:alnum:]|_|-]+$', $tplDir)) && (is_dir (DIR_WS_TEMPLATES_BASE . $tplDir))){
    // 'Input Validated' only allow alfanumeric characters and underscores in template name
    define('DIR_WS_TEMPLATES', DIR_WS_TEMPLATES_BASE . $tplDir . '/' ); 
     } else {
    if($bts_debug === TRUE) echo strip_tags($tplDir) . '<br>';
    exit('Illegal template directory!');

    And then at the top of the includes/configure_bts.php there is

      $bts_debug = FALSE;

    If you change that to

      $bts_debug = TRUE;

    then it should show you what the bad value is.


    The most likely explanation for this that I can see would be failing to run the BTS.sql file in phpMyAdmin or similar utility, as that sets the default template directory. A way to check this is to go to admin >> Configuration >> My Store and see if the three BTS configuration options appear. The default template directory should start as help.


    A second possibility is that the templates/help folder did not get uploaded to the shop.


    A third possibility is that it is looking in the wrong place for the templates directory, e.g. in the site root rather than the shop folder. This might be verified by changing the original code that I posted to

      if ((ereg('^[[:alnum:]|_|-]+$', $tplDir)) && (is_dir (DIR_FS_CATALOG . DIR_WS_TEMPLATES_BASE . $tplDir))){
    // 'Input Validated' only allow alfanumeric characters and underscores in template name
    define('DIR_WS_TEMPLATES', DIR_WS_TEMPLATES_BASE . $tplDir . '/' ); 
     } else {
    if($bts_debug === TRUE) echo strip_tags($tplDir) . '<br>';
    exit('Illegal template directory!');

    Only the first line changed, with DIR_FS_CATALOG . added. Note that I haven't tried this code, because I haven't encountered this situation. This change might get you past this error only to get a different error or erroneous behavior (rather than an error message).

  19. I have read in a few posts that STS tends to slow down a site. Is this true?
    I believe that Paul Mathot did a test of this a while back. You might find it in one or more of the BTS packages. As I recall, all three methods (stock osCommerce, STS, BTS) had similar times.


    Does it go through a generate cycle each time a page is displayed? Or does it generate an intermediate page that gets cached for subsequent displays?
    Neither STS nor BTS offer any page caching integration. I believe that the normal caching methods should still work, but don't quote me on that. I haven't tried caching with STS or the BTS. The part that stays the same from page load to page load with the STS is the template. Since the template is just a static HTML file, I'm not sure what would be cached.


    The way that the STS works is it generates the normal osCommerce page with the normal HTML and uses the PHP ob handler to capture part of the output. It then trims off the HTML that it doesn't like and uses the captured pieces to fill in values in the template file. Conceptually, the STS is wasteful. It generates an entire page to use only part of it. In practice though, the waste is entirely PHP time and is a very small part of the overall page generation.


    Also I have read that BTS separates the HTML structure from the PHP structure.
    Well, it starts to do so. Essentially how the BTS works is that it divides each file into three parts: a data part, a common HTML part, and a page specific HTML part. The data part is essentially the part of the original file that occurs before the HTML starts. The common part is the header, footer, and columns for each page. Note that this includes the head section. The page specific HTML part is what renders the central portion of the page.


    Beyond that, the BTS makes very few changes to the code. If you put the BTS files in a diff tool with the stock osCommerce files, it basically shows a bunch of lines that are the same, and then a bunch more that are in the stock file but not the BTS file. Unfortunately, there is still layout and logic integration in that.


    I understand the problems that can cause with other contributions. Being a Java developer that is extrememly logical to me. Being a developer I don't have a problem with digging into the code. As long as it had its advantages.
    I haven't had any problems installing contributions with the BTS. Since it basically just splits the relevant portions of the file into two parts (contributions usually don't change the common part--more about that later). It's just a matter of opening two files to make the changes rather than just one. It's not a mindless activity where you simply follow the instructions, but it's not exceptionally difficult either.


    With a contribution that does change the common part of the page (e.g. Jack's Header Tags SEO), you need to make the changes in the common template. This actually demonstrates the power of using the BTS. For Header Tags SEO, part of the instructions are to open as many of the files as you want to have use the system and make the same change in each file. The BTS specific instructions say to open one file and make the change to that one file. The STS instructions say to open a file and change it and then have you make three other changes to make that change work.


    In general, that's been my experience of the two. The BTS has you make the same changes but in different places. The STS has you make new changes to enable the change that the contribution would make. If someone else has already done the STS integration, you are back to just following instructions. If not, then you need to have PHP knowledge to integrate the contribution into the STS -- unless you are fortunate enough that the contribution only changes existing output that the STS passes through.


    The STS is good at allowing someone who knows HTML but not PHP to change the osCommerce layout. However, once you have it installed, you are limited to the following options: only installing contributions that are STS compatible; learning PHP and the STS so as to be able to modify contributions to be STS compatible; paying someone to integrate contributions with the STS. Obviously, the second option makes a mockery of the original reason to install STS. However, for those who are comfortable with the idea of paying to have non-STS compatible contributions integrated, it does provide the easy layout changes.


    The BTS is good for someone who either likes changing among different layouts or who simply doesn't like making the same change to thirty odd files. Like the STS, it also requires that you understand a bit about PHP and how the BTS works in order to integrate contributions (especially those that add new pages to the catalog side). I don't believe that it has ever claimed to be good for people who don't know PHP, and it isn't. It's designed for a developer to use to make changes in one place and have them affect the entire site.


    If the goal is to be able to easily allow store owners to integrate contributions, then it doesn't really matter how you change the layout of the site: manually, with the STS, with the BTS. Making significant layout and HTML changes will break existing contribution install instructions because the existing 2.2 series code does not separate layout and logic. Therefore, contribution install instructions will tell you to find the logic embedded in the existing layout and change it. If you change the layout, then the markers for the instructions are lost as well.


    The obvious solution would be the osCommerce 3 version. Its presence will keep there from being a BTS for v3 (there might still be an STS, as the purpose is different). If the goal is to have a template system for which all contributions will be available, this will be the only game in town. Of course, it hasn't been released yet, so the contribution support is not there. However, contribution support for v3 will grow, while 2.2 will start to wane.