Jump to content

Harald Ponce de Leon

Admin
  • Content count

    5,378
  • Joined

  • Last visited

  • Days Won

    125

Posts posted by Harald Ponce de Leon


  1. Hi Claudio..

     

    The MODULE_PAYMENT_PAYPAL_IPN_ORDER_STATUS_ID value is used if the callback is successful or not and does not have a relation to the "Preparing" order status. The default value of MODULE_PAYMENT_PAYPAL_IPN_ORDER_STATUS_ID is 0, which uses the default order status of "Pending".

     

    You are correct when you state the logic can be broken if the fourth order status ("Preparing") is replaced or deleted and will look at a solution by the time 3.0 is finalized.


  2. Hi Alan..

     

    If I look at the emailed order confirmation after an order is placed I see:

     

    Firstname Lastname

    Street Address

    Postcode City

    Country

     

    So for the U.S. it's missing the state and the order is incorrect. I went into admin to find the options for this and so far I can't find them. I can see in the db the osc_address_format table with 12 preinstalled options but for the life of me I can't find an admin interface for changing them or a method to apply one or the other to the emailed confirmation.

     

    Does it not exist yet or am I missing it?

     

    There is no administration page for this for the 2.2 MS 2 version - if you need to change the format it will need to be done manually in an SQL query.

     

    For 3.0, now that the address format is moved to the countries database table, changing the format can be performed when editing the country involved in the Administration Tool.


  3. Replace this file with the one located in:

     

    oscommerce/admin/includes/classes

     

    image.php

     

    That file has a different osC_Image_Admin::resize() method using the GD library.

     

    If it does not work it is because your server is running out of memory processing the images. This is especially true for the Administration Tool -> Tools -> Images synchronization routines.

     

    Anyway I think you should implement a solution for people like me.... maybe a second solution even if it ist not 100% !!

     

    Please start with using a competent hosting provider and hosting package. You certainly cannot blame osCommerce for not working on cheap $5/month hosting plans.


  4. Both ISO 2 and ISO 3 codes are needed as there are payment gateways that only accept one or the other.

     

    The zone names are currently in their native language (ISO-3166-2). Providing native definitions for the country names is also being looked into (eg, Germany vs Deutschland).

     

    This will ofcourse depend on the language. The english language would use ISO-3166 country names, however other languages should use their native country names definitions.


  5. The base files on the Catalog frontend (account.php, checkout.php, index.php, ...) contain the following bit of code:

     

      $_SERVER['SCRIPT_FILENAME'] = __FILE__;
    
     require('includes/application_top.php');

     

    There, the very first thing being done is overwriting the SCRIPT_FILENAME value with __FILE__ before starting with the logic in application_top.php.

     

    This isn't being done on the Administration Tool base files (administrators.php, backup.php, banner_manager.php, ... index.php, ...), so adding the line where SCRIPT_FILENAME is being overwritten before application_top.php is being included should fix the problems on the Administration Tool side.


  6. Sorry, I meant that similar problems were experienced on the Catalog frontend and were fixed by overwriting the SCRIPT_FILENAME value with __FILE__.

     

    I'd suggest you add the same line before application_top.php is included in the base files on the Administration Tool side, as it is done on the Catalog side base files. The Administration Tool should then work for you without any problems.


  7. Hi Mark..

     

    Can you confirm that you are only experiencing problems on the Administration Tool and not on the Catalog frontend?

     

    Similar problems were experienced on the Catalog frontend by overwriting SCRIPT_FILENAME with the value of __FILE__ on the base files (account.php, index.php, checkout.php, ...)

     

    A similar solution will be made available for the Administration Tool in the next alpha release.


  8. Manually importing the oscommerce.sql file into the database is no longer sufficient for new 3.0 based installations, as the installation procedure makes calls to the installation methods of modules to further insert data into the database.

     

    We'll look into providing a "dump" of a clean database installation to remedy this, but will not be an official installation means due to the need of a default store administrator account.


  9. Hi Giuseppe..

     

    The image resizing implementation requires the imagemagick program installed on the server to be able to manipulate the images successfully.

     

    The first implementation of the feature used GD but is not an ideal solution as it quickly consumes the available memory even when working with one image at a time.

     

    If your hosting provider has PHP safe-mode enabled, they are still able to securely allow calls to exec() by setting up a directory with approved binaries to execute. More information about this can be found with the ini.safe-mode-exec-dir configuration:

     

    http://www.php.net/manual/en/features.safe...e-mode-exec-dir


  10. What damage would occur, this is sort of new to me and would like to know more, have a link or something for further reading?

     

    I don't have any links as this was witnessed during our PHP compatibility testing.

     

    Before our minimum PHP requirement jumped to 4.1, we had something like the following for < 4.1 versions:

     

    if (PHP_VERSION < 4.1) {
     $_GET =& $HTTP_GET_VARS;
    }

     

    Which worked fine. However the following caused corruption to occur within the arrays for PHP >= 4.1:

     

    function my_function() {
     global $_GET;
     ...
    }

     

    Setting them as global was necessary incase PHP < 4.1 was used. This was than changed to:

     

    function my_function() {
     if (PHP_VERSION < 4.1) {
    global $_GET;
     }
    
     ...
    }

     

    Before getting rid of that entirely with the new PHP >= 4.1 requirement.


  11. Mark, it doesn't have the same issues.

     

    You cannot access $foo as $_GET['foo'] without register_globals enabled.

     

    The "superglobal" label means that the $_GET, $_POST, ... variables do not need to be specified as global variables within functions and class methods.

     

    eg:

     

    function my_function() {
     global $_GET; // not needed
    
     echo $_GET['foo'];
    }

     

    In fact setting the super global variables as globals would damage their content with certain PHP versions.


  12. Hi Hansi..

     

    Those would be possible with new database class modules. The database class already uses prepared statements.

     

    Actually, there might be problems with mysqli due to it's prepared statements accepting only ? placeholders and not named placeholders (what our database class uses).

     

    Are you interested in working on this area?


  13. The installation part can be taken care of similar to how the payment modules are now in the development repository. The payment modules have a "catalog" version to take care of the functions needed during the checkout procedure, and an "administration" version for the administration tool, where they can be installed, removed, and configured.

     

    The rest of the module types will follow the same style.

     

    Until we're waiting for the development server to come back online again, here is some good reading that describes the differences between MySQL FullText and Lucene (for those that don't know):

     

    http://jayant7k.blogspot.com/2006/05/mysql...sus-lucene.html

×