Jump to content

jasehead

Member
  • Content Count

    150
  • Joined

  • Last visited

Everything posted by jasehead

  1. Turned out the problem was a Safari extension. When turned off, the CubeCart modals worked OK. However, that particular extension wasn't a problem prior to upgrading the OS + Browser.
  2. First thing I did was check error logs for SQL errors, but nothing found. I agree that a mod_security rule update was probably the issue - this has been a problem in the past with my hyper-vigilant web host. I did some testing today and it seems to have been remedied.
  3. It isn't a bug in 6.1.14 either. These products were created with 6.1.14 within the last few months (and updated since then with no problem) - only in the last week or so has there been any issue, which is why I think it's due to some background server update. Upgrading cubecart is not an option because that would cause a major disruption - not looking to spend weeks fixing all the new problems from an upgrade until well after Christmas. How can I capture the SQL that is generated when a product is updated so I can show this to my webhost support?
  4. This is a recent problem, so I expect it is from some background server update rather than CubeCart. I'm running CCv6.1.14 because it's been stable and upgrades are a major disruption - so no recent changes at my end. The problem is that if the product contains CASE in the product title (pencil case, glasses case) then I can not update the product - it just defaults back to the retail storefront (probably caught as a 403 or 404 error by .htaccess and redirected). The only workaround is to make the item one word, eg. pencilcase, which is not ideal. What I want to be able to do is either: use some mod to make cubecart more robust by making sure the string is being treated as just a string, and not containing SQL commands, or capture the SQL that is generated when a product is updated so I can show this to my webhost support Any help?
  5. Just a heads up that Apple's sensitivity about blocking popups in Safari seems to have rendered any "delete" modal dialogue boxes in CubeCart useless. In 6.1.14, clicking the delete icon on a customer address or credit card details should show a modal that asks for an OK to confirm the deletion. A recent upgrade to MacOS Mojave 10.14 and Safari 12.0 has seen the behaviour change to no modal box displayed and the page hangs. It is possible to reload the page. A workaround is to copy the link from the delete icon, and paste this into the address bar to activate (skipping the modal). Or just use another browser. I have not found any settings in the Safari 12.0 browser that will allow CubeCart modals to display correctly (content blockers off, popups allow). If the modal popup method hasn't changed in later versions of CubeCart (eg. 6.2.2) then other Mojave+Safari users may find the same problem.
  6. Is there a way to get CubeCart to add the correct customer_id number to the CubeCart_newsletter_subscriber table rather than just a zero? Get signup during checkout to use the Register process rather than the newsletter subscription box process (if that's the problem)? If the customer_id is zero then, instead of matching the customer_id, fall back to matching the email address instead and getting title, first name and last name that way (eg. for mailing list export)? Verify subscribers by email address and update any with a customer_id of zero to their actual customer_id?
  7. The missing first name/last name issue happens when a guest agrees to create an account during checkout (in 6.1.14 anyway). The customer is being added to the CubeCart_newsletter_subscriber table with a customer_id of zero, which is the same as if they were signing up just using their email in the subscription box. So is the signup at checkout using the wrong process (basic newsletter signup instead of register signup)? Or maybe executing too soon, before the new customer has been signed in properly?
  8. I think that exploring the plugin in more depth is probably up to the plugin developer. Your first suggestion allowed the plugin to function without blocking the payment gateway - that's a huge improvement. There is still the CubeCart issue of first name and surname not making it to the CubeCart mailing list for new customer signup during checkout. The "Register" page works OK, but registration at checkout doesn't. Also, I see in the table CubeCart_newsletter_subscriber that some entries have a "validation" code like 51edf897c51348103717f4e05d8578e8 where others are NULL. NOTE: By CubeCart Mailing List I mean the list that can be exported from (in 6.1.14 admin) Newsletters > Export Mailing List with format: {$EMAIL_ADDRESS} <{$FIRST_NAME} {$LAST_NAME}> It's not clear to me where CubeCart is pulling this data from, so not clear why First Name and Last Name are not available for entries made during signup at checkout.
  9. @bsmither Only your first suggestion worked. The second resulted in a page that hanged for a few seconds, white screen of death, and this error in the site error log: PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 8960 bytes) in /home2/mysite/public_html/mystore/modules/plugins/SFWS_Mailchimp/hooks/class.newsletter.subscribe.php on line 108 (line number would be approximate because I have original code commented out rather than replaced)
  10. Thank you - I can undo my clumsy workaround. No subscription during signup at checkout followed by subscribe after address/shipping update works OK - through to gateway with no WSOD. First name and surname in CubeCart mailing list and sent to MailChimp OK. Subscribe during signup at checkout - through to gateway OK but still no first name or surname in CubeCart mailing list (so email address only sent through to MailChimp). No PHP Errors in the error log.
  11. 5 if(!defined('CC_DS')) die('Access Denied'); 6 7 $mailchimp_status = $GLOBALS['config']->get('sfws_mailchimp', 'status'); 8 $mailchimp_api_key = $GLOBALS['config']->get('sfws_mailchimp', 'mailchimp_api_key'); 9 $mailchimp_list_id = $GLOBALS['config']->get('sfws_mailchimp', 'mailchimp_list_id'); 10 11 if ($GLOBALS['user']->is() && !isset($email)) {
  12. I've managed to break a clean 6.2.1 store with MailChimp plugin enabled and reproduce my problem (my store is 6.1.14). - Add test product to basket - Click Checkout in Mini Basket - Fill all details, all checkboxes selected EXCEPT DO NOT SUBSCRIBE TO MAILING LIST - Card Capture as gateway - Secure Checkout button - Green banner - address updated, shipping options, logged in at top of screen, SUBSCRIBE CHECKBOX VISIBLE - Click Subscribe checkbox on this screen - Secure Checkout button (again) - Gateway fails - white screen of death (on Safari, 500 error on some browsers) So the problem seems to be if the first subscription box is empty and the second subscription box is checked. (If the first box is checked then the other should not appear.) Commenting out one checkbox seems to cause the same problem. Testing my 6.1.14 store using the same method: The first name and surname are included in the CubeCart mailing list (but no information sent to MailChimp list via the plugin) Error in the site error log : PHP Fatal error: Call to a member function is() on null in /home2/mysite/public_html/mystore/modules/plugins/SFWS_Mailchimp/hooks/class.newsletter.subscribe.php on line 11 If the MailChimp plugin is disabled then the gateway works OK My clumsy workaround was to add "disabled" to the input for the second checkbox and to comment out the label. I'm sure there's a more elegant solution that will keep the mailing_list input visible to CubeCart but invisible to the customer. {if !$USER_SUBSCRIBED} <div class="row"> <div class="small-12 large-8 columns"> <input type="checkbox" id="mailing_list" name="mailing_list" value="1" disabled ><!--label for="mailing_list">{$LANG.account.register_mailing}</label--> </div> </div> {/if} If a guest customer unchecks the subscription checkbox on during signup at checkout, then when address/shipping is updated another subscription checkbox will appear but no label text and not clickable - it looks like a small glitch and easily ignored. What it does is preserve the unsubscribe state from the original signup and so allows the gateway to function without error.
  13. On further testing, I'm finding that if the first subscription box is unchecked by the customer and the second subscription box is checked by the customer then this causes a white screen of death for the card capture gateway.
  14. I think that no name is recorded in the mailing list if the only subscription checkbox is the first one shown when the guest is filling out their address details - in that instance only the email address is recorded in the mailing list. The name is not recorded because at that point the customer is not logged in. If the second subscription checkbox shows after the address has been updated and the new customer has been logged in, then their first name and surname are included in the mailing list. However, if I force the second checkbox to show then I end up with the gateway white screen of death and the PHP error from the MailChimp plugin. So how do I fix this and ensure that a new customer's name is recorded in the mailing list (not just their email)? Maybe referenced here:
  15. I thought that the 0 or 1 value meant checked or unchecked. I understand now that the element contains a 1 value, and that value is stored if the box is checked (am I right)? So, if the value is 1 and the code contains checked="checked", that will result in the customer actually being signed up to the mailing list (ie. the value doesn't need to change because a ticked box is not just cosmetic). Also, what would be the best way to make the checkbox ticked by default for guest signup during checkout, but to show the correct stored value for an existing (logged-in) customer? === Any clue as to why first name and surname might not be making it to the CubeCart mailing list? I've upgraded Card Capture gateway from 1.0.5 to 1.0.6 and PayPal Standard gateway from 1.0.4 to 1.0.8, and the mailing list checkbox code changes above - but that's all. Previously, when I was able to get a subscription during guest signup to work, the names carried through to the list. If I unsubscribe and resubscribe from admin or logged in as the customer then the names carry through to the list OK, just not during checkout. === According to https://www.w3schools.com/tags/att_input_checked.asp , checked is fine. <input type="checkbox" name="vehicle" value="Car" checked> No difference between HTML 4 and 5, only XHTML.
  16. Good news - I've tracked part of my problem to me making the newsletter subscription checked by default (based on this thread). Still, I have a new issue of no first name or surname being added to the CubeCart mailing list OR the MailChimp list. I changed the following lines back to their original. content.checkout.confirm.php (2 occurrences) MINE - <input type="checkbox" id="mailing_list" name="mailing_list" value="0" checked="checked"><label for="mailing_list">{$LANG.account.register_mailing}</label> ORIG - <input type="checkbox" id="mailing_list" name="mailing_list" value="1"><label for="mailing_list">{$LANG.account.register_mailing}</label> MINE - <input type="checkbox" id="mailing_list" name="mailing_list" value="0" checked="checked" {$MAILING_LIST_SUBSCRIBE}><label for="mailing_list">{$LANG.account.register_mailing}</label> ORIG - <input type="checkbox" id="mailing_list" name="mailing_list" value="1" {$MAILING_LIST_SUBSCRIBE}><label for="mailing_list">{$LANG.account.register_mailing}</label> content.register.php MINE - <input type="checkbox" id="mailing" name="mailing_list" value="0" checked="checked" {if isset($DATA.mailing_list) && $DATA.mailing_list == 1}checked{/if}><label for="mailing">{$LANG.account.register_mailing}</label> ORIG - <input type="checkbox" id="mailing" name="mailing_list" value="1" {if isset($DATA.mailing_list) && $DATA.mailing_list == 1}checked{/if}><label for="mailing">{$LANG.account.register_mailing}</label> (Yes, I see that my code just above would say "checked" twice, but the problem was more likely to have been with content.checkout.confirm.php) So, if my code is breaking things, is it because of the VALUE = 0 or because the checkbox has been CHECKED (maybe there is some script that fires on the check action)? Is there a better way to make the subscription checked by default? No European customers, so no GDPR. BTW - here is another thread about newsletter subscription not working:
  17. TESTING GUEST CHECKOUT - CCv6.1.14 with MailChimp 5.1.2 plugin enabled/disabled Refresh MailChimp connections first in plugin setup: Create new MailChimp API key (done at MailChimp) Paste API into plugin setup & save Change list and save Change list back to main list then save CHECKOUT TEST 1 - all boxes ticked, guest sign up during checkout, mailchimp plugin enabled Logout first Add test product Click Secure Checkout in Mini Basket Fill all details, all checkboxes selected Card Capture as gateway Secure Checkout button Green banner - address updated, shipping options, logged in at top of screen, subscribe checkbox visible Secure Checkout button (again) WSOD - White Screen of Death (customer may abandon cart at this point) Site error log shows PHP fatal error is() on null Click browser back button Click browser reload page (if customer did not give up) Subscribe checkbox not visible Secure Checkout button Card Capture gateway displayed Order email received by admin Site error log still shows the PHP fatal error Subscriber IS added to CubeCart mailing list NO subscriber added to MailChimp list CHECKOUT TEST 2 - subscribe to newsletter but do not make store account Logout first Add test product Click Secure Checkout in Mini Basket Fill all details, but DO NOT create store account (stay as guest) Card Capture as gateway Secure Checkout button Green banner - address updated, shipping options, NOT logged in, NO subscribe box visible Secure Checkout button (again) Card Capture gateway displayed Order email received by admin NO error in site error log NO subscriber added to CubeCart mailing list NO subscriber added to MailChimp list CHECKOUT TEST 3 - mailchimp plugin DISABLED - all boxes ticked, guest sign up during checkout Required because of admin setting change (plugin disabled) Clear CubeCart caches except for image cache and if customer logged in (and depending on browser) Clear browser caches Reload page from origin Add test product Click Secure Checkout in Mini Basket Fill all details, all checkboxes selected Card Capture as gateway Secure Checkout button Green banner - address updated, shipping options, logged in at top of screen, subscribe checkbox visible Secure Checkout button (again) Card Capture gateway displayed Order email received by admin Subscriber IS added to CubeCart mailing list OTHER TESTS - try other subscribe methods - mailchimp plugin enabled Unsubscribe/Subscribe in Your Account/Newsletter Subscriptions CubeCart and MailChimp lists updated Subscribe using standard subscribe box on page CubeCart and MailChimp lists updated MY THOUGHTS The MailChimp plugin works for other subscribe methods, but not during checkout. The customer is added to the CubeCart mailing list during checkout if they select NEWSLETTER + ACCOUNT but not if they only select NEWSLETTER by itself - surely if they want newsletters but no store account that should be possible. Clicking the back button after WSOD and reloading the page (a) makes the {if !$USER_SUBSCRIBED} subscribe checkbox disappear and (b) allows the payment gateway to work, even though the plugin still seems to generate the same PHP Fatal Error. I could not get any subscription to the MailChimp list during checkout starting as a guest. I have also tried the 6.0.0 version of the plugin without luck. I've sent this to the developer as well - the plugin is simply not working for me. Just interested here in any comments specific to anything CubeCart is doing during checkout that may be contributing to the issue. Or if there's a very simple fix that's obvious to someone (not me).
  18. Line 11 is something like: if ($GLOBALS['user']->is() && !isset($email)) So that's the check for the user being logged in. I can't see any __destruct() function in the plugin itself, but there are CubeCart instances in cart.class, request.class, session.class and user.class.php that could play a role. I guess any plugin needs a safe way to check for a null value so that it can fail quietly at checkout (or use a stored variable from the page) without breaking the gateway. I think that CubeCart's guest customer signup process during checkout could be reviewed - even moving a code hook to another point.
  19. I am still getting a few MailChimp signups with the plugin, so I have to assume that parts of it are working (either general Subscribe box, register outside of checkout or profile changes). I wonder if the plugin is looking for data before CubeCart has finished processing the checkout form. Like Noodleman indicated, the "Call to a member function is() on null" sounds like it's looking for the customer to be logged in. I'm guessing any fatal error at this point is what blocks the gateways from working - meaning frustrated customers and lost sales. I'll also test using a new MailChimp API key and change the mailing list to see if that has any impact.
  20. I found that if I comment out the subscribe checkbox in content.checkout.confirm.php (in 6.1.14 lines 37-43) then the checkout works OK and there is no PHP Fatal Error from the MailChimp plugin in the site error log. Disabling the mailchimp plugin altogether also allows the gateways to function OK, but that's not the point of this discussion. This subscription checkbox had been appearing (after address/shipping refresh) because the guest customer was not properly identified by CubeCart as subscribed to the newsletter when the checkbox was ticked as the customer filled in their address details. Manually refreshing the page made the {if !$USER_SUBSCRIBED} checkbox vanish - so something changed from doing a manual page reload - but only 6 MailChimp signups over the past 8 weeks shows there is something amiss. The MailChimp plugin was working OK during 2016 and 2017 (throwing the same error but subscribing people) - shows how long it took to identify it was blocking checkout. This year we moved servers and upgraded the store from 6.0.12 to 6.1.14 - so CubeCart code changes, PHP version or extensions could be a factor. I'm in conversation with SemperFi about the MailChimp plugin, but I'm interested in any helpful suggestions specific to CubeCart 6.1.14 or the server environment/PHP requirements.
  21. Here's the thing - if I manually refresh the checkout page the green notice about new shipping options disappears and so does the subscribe checkbox that was between the address and comments field. If I click Secure Checkout after I refresh the page then the gateway works OK.
  22. I end up seeing the subscription checkbox twice. The first time is when the guest customer is filling out their details (they can subscribe to the newsletter and create an account with the store). The second time is when the address has been checked and postage rates updated and the customer is now logged in. So why (if they already ticked the subscription box) does another subscription box appear? If the customer is logged in and HAS subscribed then they shouldn't be presented with a subscription box during checkout - there are unsubscribe links in the footer and via their account (Newsletter Subscriptions).
  23. I'm not interested in the plugin. I'll handle the plugin outside of the forums by speaking directly to the developer (waiting for a response). What I'm interested in is the core CubeCart itself: why the subscribe checkbox appears twice in content.checkout.confirm.php and whether it needs to, or if the second appearance is unnecessary and I can just remove it. If it serves no purpose and is part of the problem (eg. responsible for null data), then removing it may be a simple workaround. Or maybe a code hook is available in the original checkout page but not after the address has been confirmed. There are other stores where customers occasionally experience a blank screen during checkout for different reasons, so any workaround that solves my checkout problem could be a useful road sign to others.
  24. Thanks for the predictable answer. My questions were about the second subscribe checkbox in content.checkout.confirm.php and why it's there. In 6.1.15 it appears at line 40 and again at line 159.
×
×
  • Create New...