Jump to content

ecartz

♥Ambassador
  • Content count

    3,104
  • Joined

  • Last visited

  • Days Won

    31

Everything posted by ecartz

  1. By default, it is now sent in includes/modules/notifications/n_create_account.php. Of course, if you want to change the content, that's in the template and language files. If you want to ship a new App, the best thing would probably be to uninstall and duplicate that module. Then modify and install the duplicate. That way it won't continually be replaced by modifications in the core files.
  2. ecartz

    HoneyPot Captcha

    function CheckCountryState($state, $country) { if (MODULE_HEADER_TAGS_HONEYPOT_VERIFY_STATE_COUNTRY_MATCH == 'True') { $has_zone_query = tep_db_query("SELECT COUNT(*) AS zone_count FROM zones WHERE zone_country_id = " . (int)$country); $has_zone = tep_db_fetch_array($has_zone_query); if (0 < $has_zone['zone_count']) { $db_query = tep_db_query("select 1 from zones where zone_country_id = " . (int)$country . " and (zone_code = '" . tep_db_input($state) . "' or zone_name = '" . tep_db_input($state) . "')"); return !tep_db_num_rows($db_query); } } return false; }
  3. I suspect that you were getting this prior to installing the Let's Encrypt SSL. You just hadn't noticed when it was Comodo SSL. In includes/configure.php, find all instances of http: and replace them with https: -- in particular, change the HTTP_SERVER. Set ENABLE_SSL to true. You should probably do the same with admin/includes/configure.php I'm not the best person to help with troubleshooting a PayPal problem, but you may want to check if there are any log messages giving more information. Also, perhaps check if you don't have an up-to-date https://github.com/gburton/CE-Phoenix/blob/master/ext/modules/payment/paypal/paypal.com.crt PayPal recently started requiring that file to be up-to-date. If all else fails, try asking PayPal what the problem looks like from their side. This seems a really weird problem to have. Are you sure that the customer successfully made a payment? Because I've never heard of a payment being subtracted from the customer but not added to the store. A more typical problem would be for the payment to be in the shop account but to have never notified the store. But the money should be there. I could see that happening in the midst of your SSL problems. It could have the same problem as the admin. But the customer going to PayPal and having the amount removed from the customer's account but not deposited in the shop account would be a problem with PayPal, not osCommerce.
  4. It looks like they were allowing access to the PKI files, which probably shouldn't have been in the webspace in the first place. You can almost certainly delete (or comment out) the pki lines safely. You probably should not delete the cpaneldcv lines without discussing it with your host. RewriteEngine On RewriteCond %{SERVER_PORT} 80 RewriteRule ^(.*)$ https://tymbercreekfabrics.com/$1 [R=301,L] Options +FollowSymLinks RewriteEngine On RewriteBase / should probably be Options +FollowSymLinks RewriteEngine On RewriteBase / RewriteCond %{SERVER_PORT} 80 RewriteRule ^(.*)$ https://www.tymbercreekfabrics.com/$1 [R=301,L] You should not comment out a RewriteRule without also commenting out its RewriteCond lines. E.g. either comment out every line in #added by ensys Raj Monday, August 31, 2009 RewriteCond %{HTTP_HOST} ^174\.127\.108\.43 [OR] RewriteCond %{HTTP_HOST} ^tymbercreekfabrics.com RewriteCond %{REQUEST_URI} !^/[0-9]+\..+\.cpaneldcv$ RewriteCond %{REQUEST_URI} !^/\.well-known/pki-validation/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$ #RewriteRule (.*) http://www.tymbercreekfabrics.com/$1 [R=301,L] or replace it with #added by ensys Raj Monday, August 31, 2009 RewriteCond %{HTTP_HOST} ^174\.127\.108\.43 [OR] RewriteCond %{HTTP_HOST} ^tymbercreekfabrics.com RewriteCond %{REQUEST_URI} !^/[0-9]+\..+\.cpaneldcv$ #RewriteCond %{REQUEST_URI} !^/\.well-known/pki-validation/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$ RewriteRule (.*) https://www.tymbercreekfabrics.com/$1 [R=301,L] In general, you can replace the http: with https: in those RewriteRules. That might be causing your redirect problem. As the first rule says redirect port 80 to https without the www while several later rules attempt to redirect to http: with the www Delete (or comment out) RewriteCond %{HTTPS} on RewriteCond %{REQUEST_URI} !^/[0-9]+\..+\.cpaneldcv$ RewriteCond %{REQUEST_URI} !^/\.well-known/pki-validation/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$ RewriteRule ^(.*)index.php http://www.tymbercreekfabrics.com/index.php [L,R=301] That redirects https to http (port 80). So it undoes what the first rule does. RewriteCond %{SERVER_PORT} 80 RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L] This does the same thing as the first rule. So you probably only need one of them.
  5. ecartz

    New Installation

    1. A firewall could prevent connecting to a database over the network. 2. You may not have a database. 3. You may have the wrong connection info. 4. Something else. I'd first try looking for log files. If that fails, try turning on display_errors. In some cases, you might have to contact your host for help. If this is a local server (e.g. XAMPP), try uninstalling it and reinstalling it.
  6. 1.0.5.4 is on GitHub for those who would like to install it from scratch (as opposed to updating). 

  7. ecartz

    Attribute Addon

    Have you tried installing osC 3 to see if the variations system supported what you need? I ask because porting the variations system to Phoenix seems like something that is both feasible and generally desirable. Not trivial, but possible.
  8. The problem is not that it needs to be updated with every increment. The problem is that the current version of this module requires a core change (to admin/modules.php ). So every time that the modules.php file gets updated, it wipes out the core change which then needs to be reapplied. This could be fixed by adding a hook file or database defined hook to replace the core change. The hook point was added in this commit. But no one has updated the package with that. @greasemonkey uses that hookpoint for another module requiring the same change. Someone could also modify the module to use the standard form: https://github.com/gburton/CE-Phoenix/blob/master/admin/modules.php#L40..L42. That might avoid the need for a hook. But again, no one has updated the module to to do that.
  9. You might try clearing the cache and cookies in your browser. Sometimes using an entirely different browser (e.g. Microsoft Edge instead of Chrome or vice versa) helps. Or a browser on a different computer. If you have a second RewriteEngine On line in your .htaccess, you might try deleting the second one. if you have a .htpasswd_oscommerce file in your admin directory, you might download and back it up, then delete it on the server. Then try logging in again. Make a backup of your database in general and then (separately) the administrators table in something like phpMyAdmin. Then truncate (empty) the administrators table and see if it lets you create a new administrator account. If it doesn't, restore the administrators table from your backup (which is why you back it up separately). If you can view error logs on your server, you might go look in them to see if they show any errors.
  10. https://apps.oscommerce.com/Gqql6&amp;store-pickup-shipping-module
  11. If you make the password confirmation not required, then what does it do? I.e. if you want it not to be required, the simplest thing would be to turn it off. If you want to change the behavior, duplicate cd_password_confirmation.php as something like cd_password_confirmation_pwa.php (both module and language files) and edit it. Don't forget to change the class name (to match the new file name) and the CONFIG_KEY_BASE to be something unique. And of course change the constants to match. Where? Note that $customer_details will only exist after process is run and only if it finishes successfully. So perhaps in $OSCOM_Hooks->call('siteWide', 'injectFormVerify'); and certainly in $OSCOM_Hooks->call('siteWide', 'postAccountCreation'); $OSCOM_Hooks->call('siteWide', 'postLogin'); at least on the create_account page.
  12. 1.0.5.3 is available on GitHub for those who want to do a fresh install (as opposed to an upgrade). 

  13. ecartz

    Htaccess not blocking private IP addresses?

    It should tell you your Apache version on admin > Tools > Server Info page, under HTTP Server.
  14. You're bebopping along the internet. You find an HTTP link to a site. But you want HTTPS, what do you do? The typical response is going to be to find another site. Because the typical user won't think to add an s to the http in the URL to see if it works. Particularly as browsers often hide the protocol, just showing a lock or not. There are far more users who you will lose from search engine rankings or simple browsing than by not having an up-to-date browser. Elderly browsers mostly appear in intranets with no internet access. And beyond that, this would be a core change. Each time the html_output.php file is updated, you'd have to reapply it.
  15. ecartz

    Htaccess not blocking private IP addresses?

    deny from 10.0.0.0/8 would match all 10. addresses and not match anything that does not start with a 10. The /8 is how many bits from the beginning to mask. There are eight bits in each group (thirty-two total in the four groups of numbers). So the /8 says just look at the first number. 10.179.0.0/16 would have at least worked against addresses that started with 10.179. But 10.179.0.0/30 would only match 10.179.0.0 through 10.179.0.3. Some other things to consider. What version of Apache? If 2.4 or later, do you have mod_access_compat installed? Is AllowOverride and AllowOverrideList set in a way that allows you to use mod_access from a .htaccess file? This isn't really an osCommerce question. You might get better help either from your host or from an Apache forum.
  16. ecartz

    Incorrect link on order update

    What page do you use to add a comment to the order? Have you looked for FILENAME_ACCOUNT_HISTORY_INFO on that page? Have you looked in the language file? Here it is for Phoenix: $email = STORE_NAME . "\n" . EMAIL_SEPARATOR . "\n" . EMAIL_TEXT_ORDER_NUMBER . ' ' . $oID . "\n" . EMAIL_TEXT_INVOICE_URL . ' ' . tep_catalog_href_link('account_history_info.php', 'order_id=' . $oID, 'SSL') . "\n" . EMAIL_TEXT_DATE_ORDERED . ' ' . tep_date_long($check_status['date_purchased']) . "\n\n" . $notify_comments . sprintf(EMAIL_TEXT_STATUS_UPDATE, $orders_status_array[$status]); It might be in a similar place or somewhere different for you.
  17. That wasn't the reason. Traditionally it was more expensive to serve HTTPS pages (in terms of server resources). So servers were configured to avoid it. Also, shared hosting would often share the SSL across sites. So the HTTPS_SERVER might have been a different domain than the HTTP_SERVER. Now the standard is to make the whole site HTTPS, but osCommerce still has the original configuration. Eliminating that is on the list of things to do for Phoenix, but I'm not working on it yet. Setting the HTTP_SERVER to match the HTTPS_SERVER is the near term workaround. I don't know of any client circumstance where HTTP works but HTTPS does not. Client browsers can all handle HTTPS as far as I know. And if one couldn't, the user would not be able to register, log in, or check out. Because all of those tasks require HTTPS_SERVER. So unless you are willing to make the whole site http, you can't support an "https-impaired" user anyway.
  18. ecartz

    Incorrect link on order update

    What version of osCommerce? What page are you on? The two main possibilities would be the page itself and the language file for the page.
  19. ecartz

    Notifications

    There is. A product or any product. Or (different newsletter) all newsletter subscribers or mail all customers or a single customer.
  20. $GLOBALS['customer_data']->get('password', $GLOBALS['customer_details']) $GLOBALS['customer_data']->get('email_address', $GLOBALS['customer_details'])
  21. Which is why I'm suggesting setting a payment_completed flag on all of "shipped", "delivered", etc. But what I want to avoid is where each time we have a problem like this, we add another flag that means the same thing. We already have a download flag. And I bet that if people set it, it would exactly match what you want from your statistics flag. So I'd rather rename download to payment_completed and use it both for gating downloads and for determining what to show in revenue statistics. Another alternative would be to change how the status of the order is handled from a single monolithic status to a set of statuses. Payment status: preparing; processing; deferred; completed; rejected; etc. Ship status: waiting for payment; packing; waiting for pickup; shipped; delivered. Refund status, etc. And what if people don't want those to be affected the same way? What if they want those reports (which aren't total revenue) to include incomplete orders? Are we then going to make two more flags just for those? I would rather add a Show All/Show only payment completed to those. Then people could choose which way to show it. As a matter of general principle, we've been trying to get away from third party modules relying on core configuration to operate. So if there are third party modules that have the same problem, they should find their own solution. I would be willing to compromise that for a payment_completed flag that would be used internally. But a "Show in Statistics" flag? The module should figure that out on its own.
  22. I would rather have a "payment complete" flag. Otherwise we end up with a bewildering series of flags that everyone has to set to get the desired behavior. Even though the actual desired behavior is much simpler. If payment complete, allow download. If payment complete, show in revenue statistics. When transitioning from payment not complete to payment complete, generate a notification. Alternately, I was thinking that we might create configuration just for the dashboard module that allows people to set what statuses they want the module to include. That would be a much more limited change.
  23. ecartz

    Wishlist For Phoenix

    1.0.5.2 does not change how the tep_session functions work. But if you want to write them out, the code would look like if (!isset($_SESSION['wishList']) || !($wishList instanceof wishlist)) { $_SESSION['wishList'] = new wishlist(); $wishList =& $_SESSION['wishlist']; } But I don't think that has anything to do with the issue. Note that the part that prevents the add to cart action is if (isset($_POST['wishlist'])) { If that condition is true, then it redirects the page. If it is not true, it keeps going until it reaches the add to cart action. So there's really only two things that can be going wrong. One, that condition is not being set. Two, the redirect is failing in some fashion without showing an error. The first is far more likely and suggests some kind of browser issue. For example, Lee may be using a different browser than you. Or have different browser settings. Or perhaps some other issue unrelated to the browser. For example, if Lee is using Internet Explorer, perhaps you are hitting https://stackoverflow.com/a/1903505
  24. That's a bug in 1.0.5.0. Please delete (around line 48 of admin/includes/application_top.php ) : require DIR_FS_CATALOG . 'includes/classes/hooks.php';
  25. You need to get the new hooks file. Also be sure that you are using the latest admin/includes/application_top.php and autoloader files. Gary hasn't posted the update instructions for 1.0.5.0 in the Bootstrap forum yet. Until then, you might find it easier to update if you join the Phoenix Club.
×