bsmither
-
Posts
18,013 -
Joined
-
Last visited
-
Days Won
605
Posts posted by bsmither
-
-
Not having looked deeply at any other programmer's text editor, because what I found at the time was very good, I use UltraEdit, UltraCompare, and UltraEdit Studio.
-
The Developer Tools interpretation of the source is now also correct.
-
The only fault I have found so far is a mismatch in the hierarchy of the Billing Address area.
<div class="panel-heading">Billing Address</div> <div class="panel-body"> <div class="row"> <div class=""> <dl>...</dl> <address> <dl>...</dl> <div id="address_form"> <dl>...</dl> <div class="row"> <dl class="col-xs-6">...</dl> <dl class="col-xs-6">...</dl> </div> <div class="row"> <dl class="col-xs-12 col-sm-6">...</dl> <dl class="col-xs-12 col-sm-6" id="state-list_wrapper">...</dl> </div> </address> </div> </div> </div> <div class="well well-sm"> <input type="checkbox" name="delivery_is_billing" id="delivery_is_billing" checked="checked"> <label for="delivery_is_billing">Deliver to billing address.</label> </div> </div>
The </address> and the following </div> need to be swapped.
Normally, the browser is sort of forgiving for situations like this. But experience has shown that an extra or missing <div> tag can cause all sorts of mysterious behavior.
I have the source of the Basix skin template "content.checkout.confirm.php", near lines 282-283. These are the lines that get swapped.
Whether that fixes reCaptcha, I do not know.
After making the skin edit, you may need to clear CubeCart's internal cache.
-
You say the reCaptcha at checkout doesn't work with Foundation either? Did you change anything about Foundation?
-
The Developers Tools are showing a location of the closing </form> tag in a different location than the raw source code (which is in the correct location).
Still looking.
-
Have you modified the Basix template "content.checkout.php" or any of the other templates used at this stage?
I ask because looking at the source as revealed in my browser's Developer's Tools, I find the HTML that acts as the g-recaptcha area sits outside the one and only <form>...</form> block.
Also not in the <form> block is the Additional Comments text entry field, and everything below it.
So, let's double check how the sub-templates are placed in the main checkout template, specifically finding where the <form> tags are.
-
Did the reCaptcha used to work for you with any prior CC64X version?
-
Sorry, I do not understand where you are finding this list.
-
Would you also be logging in and out of the storefront?
I have found that CubeCart uses the same cookie for the storefront and admin backend.
Meaning, if working in the admin, and then also having logged in using a test customer account -- using the same browser, then logging out of the customer account, CubeCart destroys the cookie. Thus, you find that you are also logged out of admin.
For a second observation, when I switched my server environment from Win2003 to Linux, I was getting logged out of admin frequently. It took me a few days to realize that I was getting logged out very close to five minutes and 35 minutes after the hour, every hour.
Eventually, I learned that installing PHP on the Linux box also created a system event to be executed at these times to clear out all PHP sessions. I stopped the system from doing that.
In the file /classes/session.class.php, there is a variable $_session_timeout having the value of 604800 (seven days).
When in admin, use your browser's Developer Tools to examine the cookie CubeCart gave you. That cookie will have an expiration date that should be for seven days. (Note: every time you ask for a page from CubeCart, the cookie's expiration date should get reset for another full seven days.)
-
I use these settings:
Sending Method: SMTP with TLS (Recommended)
Outgoing SMTP Host: smtp.gmail.com
Outgoing SMTP Port (Default 25): 587
Use SMTP Authentication: Yes
SMTP Username: <whatever>
SMTP Password: <specially-acquired app password> -
Just to follow up to make the comment that there exists an alternate set of code edits -- not that these edits are any less than optimal -- if and only if the admin also checks the box for each row edited, but keeps the drop-down selectors at Don't Change and Do Nothing.
-
In /sources/orders.index.inc.php:
Find near line 720: } elseif (isset($_GET['search'])) { Change to: } elseif (isset($_POST['sold_site'])) { foreach ($_POST['sold_site'] as $order_id => $site_name) { $GLOBALS['db']->update('CubeCart_order_summary', array('sold_site' => $site_name), array('cart_order_id' => $order_id)); } $GLOBALS['main']->successMessage("One or more orders were updated with their sold site."); } elseif (isset($_GET['search'])) {Line 50 of the template needs fixing:
From: <td><span class="editable" name="sold_site[{$order.order_id}]">{$order.sold_site}</span></td> To: <td><span class="editable" name="sold_site[{$order.cart_order_id}]">{$order.sold_site}</span></td>
And there is something I don't like about lines 35-37 of the /source/ file code. When clicking a submit button (Go, Save, Search), the 'search' form elements do show up in the POST, although there are no values with them. That will cause an httpredir with everything in POST put in the querystring. That is very non-optimal.
Change line 36 from: httpredir('?_g=orders&'.http_build_query($_POST)); To: if (array_walk_recursive($_POST['search'],function($v,$k)use(&$aSearch){$aSearch=sprintf("%s%s",$aSearch,$v);},$aSearch) && !empty($aSearch)) httpredir('?_g=orders&'.http_build_query($_POST));You might need to have CubeCart clear its internal cache because of the fix in the template.
Test extensively.
-
It is easy enough to add a [Save] button, but that [Save] button will do exactly the same as the [Go] button.
Please show us the new code that was added for the new 'sold_site' column on the Order listing table.
-
It's my suggestion that your code would be above that line (which is near line 720 in CC647 admin skin).
Do you have any code to process that new column?
Has there been any prior discussion on the forum about customizing your admin skin to do this?
-
In the admin /source/orders.index.inc.php file, where is it that you have placed the new code that processes your newly editable field?
I would suggest just above near line 720:
} elseif (isset($_GET['search'])) {Your code would start with:
} elseif (isset($_POST['sold_site']) && !empty($_POST['sold_site'])) { ....The Request Payload should be more than what you have shown above:
-----------------------------234527848935122883861447253878 Content-Disposition: form-data; name="multi-status" -----------------------------234527848935122883861447253878 Content-Disposition: form-data; name="multi-action" -----------------------------234527848935122883861447253878 Content-Disposition: form-data; name="go" Go -----------------------------234527848935122883861447253878 Content-Disposition: form-data; name="search[order_number]" -----------------------------234527848935122883861447253878 Content-Disposition: form-data; name="search[search_customer_id]" -----------------------------234527848935122883861447253878 Content-Disposition: form-data; name="search[status]" -----------------------------234527848935122883861447253878 Content-Disposition: form-data; name="search[date][from]" -----------------------------234527848935122883861447253878 Content-Disposition: form-data; name="search[date][to]" -----------------------------234527848935122883861447253878 Content-Disposition: form-data; name="month_purge" -----------------------------234527848935122883861447253878 Content-Disposition: form-data; name="token" 9f4e62fbad1f0e1fc50fec49d936b7e2 -----------------------------234527848935122883861447253878-- -
What field (column) is editable? Has it ever saved before?
Please use the browser's Developer's Tools, Network screen.
When clicking the Go button, the Network screen will show a POST entry. Highlight the POST entry and look at the Request Payload. Is your form element listed?
-
True, there is no Save button on the Orders List page.
As a temp work-around, there is a pair of drop-down selectors below the list that defaults to "Don't Change" and "Do Nothing". But pressing the Go button will submit the form which comprises the entirety of the table.
-
For users of the Stripe module version 3.0.7, please see:
https://github.com/cubecart/v6/issues/3046 https://github.com/cubecart/v6/issues/3050 -
After working with another CubeCart user who allowed for intense troubleshooting efforts, it has become apparent that Stripe updated its internal API (as of 1 Aug 2022) that does now cause the Stripe module to throw an Exception, and crashing PHP.
Please see:
https://github.com/cubecart/v6/issues/3050 -
I think nearly all of the log entries matching the examples shown in the document provided, relate to the parts of the skin template system you have stripped out (Language chooser, Featured box, Sale Items box, Newsletter box, Live Help, Debug, and Skin chooser).
Looking at the source HTML delivered to my browser, I see that there is a removed text entry field for the person's phone number.
This will cause the form to not even be submitted if the form validation fails.
In the file /skins/ho/js/3.cubecart.validate.js, at lines 66-97, there are the rules for the contact form.
Remove 92-94: }, 'contact[phone]': { phone: $('#validate_phone').text() Remove 83-85: }, 'contact[phone]': { phone: trueWhat I do not know is this: How smart is the Validator? If the Validator does not find a text entry input field having the name contact['phone'], even with a rule referencing it, will the validator still submit the form?
According to this, the Validator does not check non-existing fields (from five years ago):
https://forum.jquery.com/topic/jquery-validate-check-that-a-field-exists-before-validatingIn other words, I do not know if this edit will fix things.
FYI: The core code in cubecart.class.php, says only that 'email', 'name', 'subject', 'enquiry' are the only required fields. So maybe an issue will get posted in the Github that compares the Validator rule for the phone being required, but the core code does not.
-
1
-
-
In the admin template customers.index.php:
Find near lines 148-149: <option value="1" {if $CUSTOMER.type==1}selected="selected"{/if}>{$LANG.customer.title_key_registered}</option> <option value="2" {if $CUSTOMER.type==2}selected="selected"{/if}>{$LANG.customer.title_key_unregistered}</option> Reverse the order of these two lines: <option value="2" {if $CUSTOMER.type==2}selected="selected"{/if}>{$LANG.customer.title_key_unregistered}</option> <option value="1" {if $CUSTOMER.type==1}selected="selected"{/if}>{$LANG.customer.title_key_registered}</option>
Be sure to have CubeCart clear its internal cache -- rendered skin templates are cached.
-
So you are asking to have the drop-down selector default to 'Unregistered Customer'?
-
Automatically? Or on the admin's per-customer needs?
If per-customer, bringing up the Edit screen for a customer, there is a drop-down selector to make the change.
To review, a customer is 'registered' if they create a store account through CubeCart's Registration page. A customer is 'unregistered' if the customer goes through checkout without having created a store account.
If 'automatic', I'm curious to know your reason to have all customers' type set automatically as 'unregistered'.
-
Let's start a new topic.
Present my store as a Catalogue only (for few weeks), users place order and payments shall be handled offline.
in Install & Upgrade Support
Posted
In Catalogue Mode, customers are not even able to add items to a shopping basket. So, there is no way for CubeCart to log what the customer wanted.
The admin can try to not enable any Payment Gateways. A shopping basket should be created and an Order Summary created, which the store owner can review and amend in CubeCart's administrative backend. But there will be no means for the customer to actually pay for the items via CubeCart.