Jump to content

ecartz

♥Ambassador
  • Content count

    3,760
  • Joined

  • Last visited

  • Days Won

    64

Reputation Activity

  1. Like
    ecartz got a reaction from domiosc in Information Pages SEO addon   
    If you changed that from functions to a class in includes/classes or under includes/modules, you could get rid of the catalog core changes.  Because when the autoloader sees something like
    info_pages_class::call_method It would automatically load includes/classes/info_pages_class.php if it exists. 
  2. Like
    ecartz got a reaction from domiosc in Information Pages SEO addon   
    If you changed that from functions to a class in includes/classes or under includes/modules, you could get rid of the catalog core changes.  Because when the autoloader sees something like
    info_pages_class::call_method It would automatically load includes/classes/info_pages_class.php if it exists. 
  3. Like
    ecartz got a reaction from Demitry in which payment module do you use in your shop ?   
    But they have to be stored separately, in an encrypted table, possibly in a separate database.  For example, at Amazon.com they are stored in what are called the credit card motels.  The CC motels are not on the internet.  To access them, Amazon.com has special servers that communicate with the motels via serial ports (actual physical cables).  And while those servers are also networked, they are deep behind the Amazon firewalls. 
    The osCommerce CC module didn't do any of that.  It would be possible to do that, but that's not the right module.  And I don't know that anyone is going to write such a module, as the requirements are stringent and the liability is high. 
    And it's not actually required to store the CC number in order to access the credit card for repeat purchases.  It is also possible to store just a reference to the credit card.  Then Visa or MC or whatever can bill the right account.  They just need to track which of these identifiers are associated with which account.  That's strictly safer, as the credit card info only needs to be given once and is never stored at all (except possibly for the last four digits, which are often used for identification).  It's even possible that Amazon.com does it that way now.  I don't know what has happened there since 2008. 
    Meanwhile, any payment processor is now responsible for seeing that merchants are PCI compliant.  So rather than have you take the credit card details and then communicate the information with them manually, they are going to want to see a whole system that processes the information in an automated fashion.  Usually they do this by giving you a payment gateway to use and asking you to integrate with it either by passing the credit card information immediately or by switching the customer to them to collect the credit card details. 
    The days of taking the credit card information and then typing it into the machine or phoning them in for authorization should be over.  Payment processors should keep you from doing that now, partially by requiring a CSC/CVV, which as you note, should never be stored. 
    Well, go ahead.  But you still need to get someone to answer the authorization requests, possibly with a test server.  I used to have several accounts for that, e.g. on PayPal's sandbox and Authorize.net's test servers.  It may be possible for you to sign up for them, although it's my understanding that the requirements have been getting more and more stringent.  And that would then limit you to payment processors who support that particular gateway.  For example, PayPal is the only processor that uses the PayPal gateway for authorizations.  Authorize.net covers more processors, but not every processor (for example, I don't believe that you can use Authorize.net with PayPal as the processor). 
  4. Like
    ecartz got a reaction from valquiria23 in Reminder: Frozen EOL   
    With software, it means that it won't get security updates. 
  5. Like
    ecartz got a reaction from TomB01 in USPS Rate V4, Intl Rate V2 (official support thread)   
    The ones that remain are the ones that change from store to store.  For example, your catalog directory might be in the root at / or at /catalog/ or at something like /shop/.  Each store can choose to do something different.  Meanwhile, images/icons/ is always images/icons/ -- there is very little reason to ever change it.  Even if you did want to change it in the URL, you could use something like mod_rewrite so that the directory structure would stay the same. 
    In general, most of the constant ones have gone, leaving only the few variable choices.  I find it rather unlikely that we'd take out more of the DIR_WS values (except possibly DIR_WS_HTTPS_CATALOG).  More likely to go would be HTTPS values and USE_PCONNECT.  USE_PCONNECT because mysqli does that in the DB_SERVER.  The HTTPS values because very few stores used mixed HTTP and HTTPS today.  So why support something that no one uses? 
    The two DIR_FS_DOWNLOAD values may go.  And STORE_SESSIONS. 
    The following are pretty safe, although the HTTP ones might get renamed (or not): 
    define('HTTP_SERVER', ''); // eg, http://localhost - should not be empty for productive servers define('HTTP_COOKIE_DOMAIN', ''); define('HTTP_COOKIE_PATH', ''); define('DIR_FS_CATALOG', dirname($_SERVER['SCRIPT_FILENAME']) . '/'); // define our database connection define('DB_SERVER', ''); // eg, localhost - should not be empty for productive servers define('DB_SERVER_USERNAME', ''); define('DB_SERVER_PASSWORD', ''); define('DB_DATABASE', 'osCommerce'); DIR_WS_CATALOG is defined elsewhere, but also pretty safe. 
  6. Like
    ecartz got a reaction from TomB01 in USPS Rate V4, Intl Rate V2 (official support thread)   
    I wouldn't say it that way.  What should be replaced is
    " . TABLE_CONFIGURATION . " and it gets replaced with
    configuration So that the string looks like
    insert into configuration ( It will sort of work if you replace TABLE_CONFIGURATION with configuration, but it will generate a notice that may appear in the logs.  And of course if anyone ever made a constant named configuration, it would break. 
    Normally, I'd recommend replacing
    $this->icon = DIR_WS_ICONS . 'shipping_usps.gif'; with
    $this->icon = DIR_WS_CATALOG . 'images/icons/shipping_usps.gif'; Because that will work regardless of where the catalog directory is located. 
    If you use the <> tool to insert code in the forums, it will be easier to tell it from the surrounding text. 
  7. Thanks
    ecartz got a reaction from Chadduck in Google XML Sitemap SEO   
    Found it.  The App is called Store Configuration Monitor and it has a bug in its helper functions.  In admin/includes/functions/general.php change the two functions to
    function tep_configuration_update($cID, $configuration_value) { $configuration_values_query = tep_db_query("select configuration_value, configuration_title, configuration_description from configuration where configuration_id = '" . (int)$cID . "'"); $configuration_values = tep_db_fetch_array($configuration_values_query); tep_db_query("insert into configuration_changes (change_date,previous_setting,new_setting,change_title,change_description) values (now(),'". tep_db_input(tep_db_prepare_input($configuration_values['configuration_value'])) ."','". tep_db_input(tep_db_prepare_input($configuration_value)) ."','". tep_db_input(tep_db_prepare_input($configuration_values['configuration_title'])) ."','". tep_db_input(tep_db_prepare_input($configuration_values['configuration_description']))."')"); // Check to see if the configuration value changed is the Store Owner's Email address - if it is send a configuration change notification to the existing Email address on file. if($cID == 3) { tep_mail(STORE_OWNER, $configuration_values['configuration_value'], EMAIL_CONFIGURATION_CHANGE_TEXT_SUBJECT, EMAIL_CONFIGURATION_CHANGE_TEXT_BODY, STORE_OWNER, $configuration_values['configuration_value']); } tep_mail(STORE_OWNER, STORE_OWNER_EMAIL_ADDRESS, EMAIL_CONFIGURATION_CHANGE_TEXT_SUBJECT, EMAIL_CONFIGURATION_CHANGE_TEXT_BODY, STORE_OWNER, STORE_OWNER_EMAIL_ADDRESS); } function tep_module_change($action, $class) { tep_db_query("insert into configuration_changes (change_date,previous_setting,new_setting,change_title,change_description) values (now(),'','". tep_db_input(tep_db_prepare_input($action)) ."','". tep_db_input(tep_db_prepare_input($class)) ."','')"); tep_mail(STORE_OWNER, STORE_OWNER_EMAIL_ADDRESS, EMAIL_CONFIGURATION_CHANGE_TEXT_SUBJECT, EMAIL_CONFIGURATION_CHANGE_TEXT_BODY, STORE_OWNER, STORE_OWNER_EMAIL_ADDRESS); } Then you should be able to update values normally in admin. 
  8. Like
    ecartz got a reaction from greasemonkey in UPS XML 1.7 for Phoenix   
    Well, right now we don't have the necessary hook.  So let's add it.  See here.  Find
    $action = (isset($_GET['action']) ? $_GET['action'] : ''); Add before it add
    $OSCOM_Hooks->call('modules', 'preAction'); Now, in includes/hooks/admin/modules/ create a file called canadapost.php or upsxml.php or whatever.php.  I'm going to proceed as if named whatever.  In that file, create a class named hook_admin_modules_whatever, e.g.
    class hook_admin_modules_whatever { function listen_preAction() { if (isset($_GET['module']) && 'whatever.php' == $_GET['module'] && isset($_GET['action']) && 'save' == $_GET['action'] && isset($_POST['configuration'])) { foreach ($_POST['configuration'] as $key => &$value) { if (isset($value) && is_array($value)) { $value = implode(', ', $value); if (false !== strpos($value, '--none--')) { $value = str_replace(', --none--', '', $value); $value = str_replace('--none--, ', '', $value); $value = str_replace('--none--', '', $value); } } } unset($value); } } } My suggestion would be that whatever should be the name of the module.  Note that in the
    'whatever.php' == $_GET['module'] whatever must be the name of the module. 
    After you test that this works, I'll ask Gary to make the core change so that in future versions, you don't have to change admin/modules.php
  9. Like
    ecartz got a reaction from valquiria23 in Error installing Phoenix 1.0.4.0   
    I made the edits at https://github.com/ecartz/CE-Phoenix/blob/warn_php_version/install/templates/pages/index.php if you want to try to convince Gary to integrate them. 
  10. Thanks
    ecartz got a reaction from Moxamint in Product listing   
    It makes the layout harder to calculate.  Because if the width is set, then the height can change.  Or if the height is set, the width can change.  Consider specifically the situation where the canonical value is set to 300, considering a 300x300 image.  On some products, the image might be 300x60 and on others 300x2100.  Will it look good to mix products where some are 35 times as tall as others?  Or 50x300 and 2000x300.  Some products are most of the width of a screen while others take up just a fraction. 
    If you specify width and height, you can make all the images fit into that box and automatically extend the ones that need it.  So a 300x60 image will get 240 rows of padding.  While the 300x2100 will be resized to something like 43x300 and receive 257 columns of padding.  This gives each product a predictable size in the display. 
  11. Like
    ecartz got a reaction from valquiria23 in Error installing Phoenix 1.0.4.0   
    Phoenix requires PHP 7+
    If you want to fix the error, change
    $module_width = $ad->content_width ?? 6; to
    $module_width = isset($ad->content_width) ? $ad->content_width : 6; and that particular line will work again.  But expect more problems if you try to run Phoenix on PHP 5. 
  12. Like
    ecartz got a reaction from valquiria23 in Error installing Phoenix 1.0.4.0   
    Phoenix requires PHP 7+
    If you want to fix the error, change
    $module_width = $ad->content_width ?? 6; to
    $module_width = isset($ad->content_width) ? $ad->content_width : 6; and that particular line will work again.  But expect more problems if you try to run Phoenix on PHP 5. 
  13. Thanks
    ecartz got a reaction from magak2015 in [CONTRIBUTION] Ultimate SEO URLs v2.1 - by Chemo   
    I do not know the answer.  But if I were trying to do this, I would look at sitemap Apps. 
    Why?  Because they generate listings of URLs and should use the same generation mechanism as osCommerce uses for regular links.  Perhaps not all of them would be compatible with this App, but at least one should. 
  14. Like
    ecartz got a reaction from LeeFoster in [Contribution] Multi Pickup   
    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. 
  15. Like
    ecartz got a reaction from sandipmakwana in Quantity box with plus and minus buttons   
    Does the plus/minus buttons contribution actually update the cart without a page refresh? Or does it instead update the page and then you submit the quantity when you click the add to cart button (which refreshes the page)?
     
    And the fast update contribution submits the page every time you delete a product or change the quantity, right? So you want to be able to make all your quantity updates before updating the cart (like you would normally do)? There might be user confusion in that they will have changed the quantity on the page but never submitted the page so that it is not updated on the server.
     
    What happens on a delete? Should it update the quantities? Or just delete the item? I think that the way it works now, you would have to update the quantities, just as if you had clicked the update cart button. Or you would need to remove the instant delete so that it only deletes when you click on the update cart button (the original way that the cart worked). Or you would need to redo the instant delete functionality (unfortunately without help from the plus/minus contribution, which doesn't deal with multiple products).
     
    Does it sound like I'm understanding what you want to do? I haven't used these particular contributions previously, so I may be misunderstanding somewhere.
  16. Like
    ecartz got a reaction from caminho in Basic Template Structure 1.7   
    When I upload it, BTS 1.7 will be updated to the 2.2 RC2a standards. From the changelog:
    The Basic Template Structure location in the contributions area remains the same.  
    There is no functional improvement in this release. The only changes are to increase compatibility with RC2a. Therefore, no upgrade instructions have been provided. If you are using an older version, you can continue to do so. If you launch a new RC2a store, you can use this version.
×