Jump to content

Harald Ponce de Leon

Community Team
  • Content count

    5,379
  • Joined

  • Last visited

  • Days Won

    130

Posts posted by Harald Ponce de Leon


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


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


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


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


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


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


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


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


  9. 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?


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


  11. With regards to the Zend Framework I am interested in the Lucene search module which I haven't had the chance to try yet. One thing I found when running my last webstore was people weren't getting great search results. This might be a good solution to making search work better (and faster with lots of products). MySQL's full text search could also be used but would mess with your database independance goal later on.

     

    What do you think of creating subclasses to handle the searching? Subclasses could be made for the different database servers (first for MySQL) and for non-database-servers (Zend_Search_Lucene, mnoGoSearch).

     

    A main osC_Search class could then be used to define the search parameters, and calls the defined subclass to execute the search.


  12. Hi Ben..

     

    Avoid PHP5: At least for 3.0 release. As much as I love it most shared hosts haven't caught up with the future yet and it may harm adoption of the new release.

     

    The 3.x releases will be supported by PHP 4.1+.

     

    We would however like to prototype with PHP 5 and if it turns out successful, it could start for the v4.0 release.

     

    Unit tests: Tests are your friends, would also be good to require them in the above point

     

    Are you able to help here in some form?

     

    Follow some specific code style guidelines when accepting code from others PEAR??

     

    We do have coding standards in place (found on the development server). We do not intend on including Pear classes due to the dependencies they have with other Pear classes (which is how their "framework" works).

     

    There is however interest in the Zend Framework and would also like to prototype with it's classes for our next generation framework.

     

    Such points are mentioned on the following page on the development server:

     

    http://svn.oscommerce.com/trac/wiki/Development/PlanAndIdeas

     

    Database Separation: I quite like the DAO/VO pattern myself

     

    Are you also able to help here in some form?

     

    Thanks for your feedback!


  13. Hi Greg..

     

    HPDL mentioned on IRC that he'd like people who want to help to write something on the forum along the lines of what they're skilled with and what we'd be interested in doing. I figured I should start a thread for such things in this section - hopefully it's in the correct place.

     

    Developers introducing themselves should actually start a new thread so that the flow of discussion inside an existing thread is not interrupted.

     

    In terms of what interests me: UI are pretty uninteresting to me, I prefer to work on back-end stuff. I'll write whatever needs to be (re)written.

     

    Great! Is there a particular area you have interest in addressing? By particular area I mean something like the core framework (class relationships), templates, modules, boxes, ...

     

    This is pretty open at the moment - if you prefer to have to have something assigned then we can talk more about this on IRC (as we a both active there), and forward the results here.

     

    I also volunteer my internationalization system if it'll help.

     

    What do you mean by your internationalization system? If you mean translations for a language pack, that would be a good and fast starting point :)


  14. Hi Anders..

     

    Yes, too many people were accessing the repository at the same time the Germans were searching on the German Community Support Forums :D

     

    The server is back online but direct access to the repository has been disabled until the development site has moved to its own dedicated server. Please keep an eye on the news announcement thread concerning the development server, as that is where the progress is being kept up to date.

×