bsandall
-
Posts
222 -
Joined
-
Last visited
-
Days Won
11
Posts posted by bsandall
-
-
The problem with that is there is no guarantee that the store admins will set a default for all required options on every single product that has options. The ability to even set a default was only introduced in 6.1.6 and there are thousands of stores out there with tens or hundreds of thousands of products - I highly doubt everyone has had time to go through and set default options, and many stores might not even bother as it may not be something that is required for their business model.
That said, I do see what you are saying. Yes, the product price fields are redundant for the type of use case you have. CubeCart is not set up to efficiently query a price from a set of options, however, especially considering that option prices can be either absolute or cumulative. It would be a mess trying to determine prices for all of the products displayed on the home page or in a category, so CubeCart takes the route of having an easily retrievable price at the product level. This seems to me to be a good compromise for the sake of site speed and ease of use.
However, the potential for data inconsistency could be addressed by providing some method of auto-setting the product price based on the default options, e.g. when saving the product. Normal price would be easy, but how would you propose determining sale price? How about cost?
For my own store, I solved that issue by modifying the code to have a 'Price' and 'Sale Price' field for each entry in the options matrix. Non-required options can still modify those prices, but any required options I don't even bother setting price adjustments at the option level - just in the options matrix.
-
1
-
-
Interestingly, the reCAPTCHA sidebar won't even display anymore in Firefox (it did once before I tried registering an account), even in a private window after clearing the cache, which means I can't do anything that requires the verification code. No challenge is given and I cannot submit the contact or registration forms.
It still shows up in Chrome and those forms work fine, just not checking out as a guest.
I'll try restarting my browsers tomorrow and see if that gets me anywhere.
-
reCAPTCHA stores your browser fingerprint along with other data such as your computer's hardware configuration; once you have proven that combination to belong to a human, it is very unlikely to challenge you again unless you start using a different browser, hardware, or both.
Do you get challenged if you try again now with a bogus email address?
-
To clarify, the reCAPTCHA is working fine when registering as a customer - I've had challenges pop up for me and succeeding at them allowed me to continue registration.
The only case I've found where it failed (and no challenge popped up) was checking out as a guest.
Also, I don't think the reCAPTCHA necessarily catches bad email addresses, at least not as the only indicator.
For example, I was only challenged by reCAPTCHA to prove I am human the first time I tried to create an account even though I used my full name and a real email address; later in a private browser session it let me pass despite me typing my name as 'B S' and email as '[email protected]'.... -.-
-
Store is on 6.1.7 and has SSL enabled.
Enabled Invisible reCAPTCHA.
I am able to register new accounts, log in, and checkout as a logged in customer.
I am also able to create an account during checkout and proceed as normal.
However, trying to checkout as a guest, i.e. not creating a registered account, does not work.
Upon entering the customer data and clicking either `Update Basket` or `Secure Checkout`, the error message `The verification code was incorrect. Please try again` appears, indicating that reCAPTCHA failed to verify that I am human. No reCAPTCHA dialogue box popped up to select images or anything.
Once that fails, the email address I had entered has been cleared and any further attempt to proceed after re-entering an email address is met with the `Please enter a valid email address` error.
For now, I've simply disabled reCAPTCHA so as not to interfere with my customers' experience.
Has anyone else experienced this issue? Anyone know of a fix?
Cheers.
-
Unfortunately there isn't yet a way for CubeCart to automatically determine the correct price, and it would probably be computationally somewhat expensive to do so (i.e. the site would be slower to load).
You can avoid such a discrepancy, however, by setting the product's price to whatever the price is for the product with the default options selected.
So in the case of the screenshot above, you should set the price for 'Test Product' to 150 Euros and remove the sale price. The customer will then see the price as 150 Euros wherever the product may be displayed, and that is the price for the default version of the product.
-
It should look like the attached photo when you are creating or editing a product's options.
-
Did you edit your product(s) so that the assigned options have a default set?
Are you using a customized skin? If so, you will need to manually integrate the changes made in the commit I linked to earlier.
-
The ability to set default options was added in 6.1.6.
-
1
-
-
Your customer would probably appreciate it if you scrubbed any personally identifying information from that image.
While it's too late to stop the information from ever having been posted, it's not too late to mitigate its exposure by editing your post and removing the image until such time as you can edit it and repost it.
-
On 3/11/2017 at 9:18 AM, Dirty Butter said:
I tried our test site with stock search as of current GitHub commit, but it still has the same issues I had before.
Is your test site running any custom code? Because I've tried searching e.g. ' M&M ' in both Firefox and Chrome using stock code, and both will return results provided I have an 'M&M' product. In other words, I am unable to reproduce your issue.
Speaking of which, I saw you mention in the other thread that special characters were causing your searches to fail (back in 2012) - that's fixed as of #1520. So if you have an 'M&M' product and put "M&M's" somewhere in the product description, that product would be returned for either of those search terms, whereas neither would work previously.
Since you seem to have a lot of customizations, you may need to hire a developer or open a support ticket (if Al accepts them for modified sites) to resolve your issue.
EDIT: Actually, the apostrophe, while encoded correctly, didn't turn up any search results with the default search code, even after adding "M&M's" to the product description.
-
23 minutes ago, Dirty Butter said:
My Search code is far from stock - the line before you said to add code uses RLIKE instead of Fulltext.
Ever since this change by Al, it is no longer necessary to force 'RLIKE' in the function declaration. Searching for e.g. 'A1' will return results despite being only 2 characters in length, unlike previously.
You may want to consider using stock code for your search functionality. If there is something you have added that you can't do without and that isn't possible with the stock code, you may want to look at re-implementing it using the current code as the chassis.
-
Have you customized your Catalogue class' searchCatalogue function?
Do you have any plugins that interact with the search query?
With the current code, you shouldn't end up with ' ' in a search query, though it may get logged that way (I'd have to double-check, but I think the log may send some data through htmlentities which would cause an unencoded space to appear that way).
If you can, enable debugging and search 'Snoopy ' on your store, then check the debug output at the bottom of the screen. As long as you are not seeing ' ' at that point, you should be okay.
-
MySQL typically ignores leading and trailing whitespace when performing searches (with the '=' comparison, and CubeCart already removes white space by using that to split the search string), but the spaces (among other things) were being deformed during the redirect process. This was fixed in GitHub issue # 1520.
Trying a search on my own store with an extraneous space (or more, both before and after) returns results as though no space were there.
In other words, you shouldn't need to edit anything - just pull the latest code from GitHub =)
-
Note that JavaScript is also cached and, with the changes that have been / are being made to the way images display, it can negatively impact the customer experience.
You can apply the same trick to JS files, notably in main.php toward the bottom, you'll find:
{foreach from=$JS_SCRIPTS key=k item=script} <script src="{$STORE_URL}/{$script|replace:'\\':'/'}" type="text/javascript"></script> {/foreach}
Add the same thing '?v=1' to that so it looks like:
{foreach from=$JS_SCRIPTS key=k item=script} <script src="{$STORE_URL}/{$script|replace:'\\':'/'}?v=1" type="text/javascript"></script> {/foreach}
Note that according to some answers on StackOverflow, adding this query parameter will not negatively impact the browser's ability to cache the file, it will just force it to refresh any time the parameter changes.
-
Use PHP's trim function on each of the search terms.
In catalogue.class.php, under the searchCatalogue function, you can try adding the following as the first few lines of that function:
public function searchCatalogue($search_data = null, $page = 1, $per_page = 10, $search_mode = 'fulltext') { if (is_array($search_data)) { array_walk($search_data, 'trim'); } else { $search_data = trim($search_data); } ...I haven't tested that, but it should be pretty close.
-
On 2/25/2017 at 3:53 PM, Dirty Butter said:
I tried to follow @bsandall directions for making edits by using your own GitHub. It was just past me. But maybe you need to look into it - as I understand it, it's supposed to make it possible to easily roll back any edits.
I've tried searching for his post, but not having any luck. Won't help you right now, but might keep this from happening again.
You know, I did start writing up a tutorial on this topic a while back, but never got around to posting it. I'll have to dig it up at some point as it can make a world of difference when handling customisations.
-
Please note that your customers will not automatically refresh so many will be stuck with that large, unwieldy icon.
To force your customers' browsers to refresh the CSS, you can do this simple trick:
Open the /skins/foundation/templates/main.php file (or the equivalent for your skin)
Find the <head> link to 'cubecart.css'
Add '?v=1' to that link.
In the end it should look like this:
<link href="{$STORE_URL}/skins/{$SKIN_FOLDER}/css/cubecart.css?v=1" rel="stylesheet">
Whenever you make a major change to your CSS that will cause the store to look crappy for customers if they have a cached version, change the v=1 to v=1.1 or whatever.
-
Al posted a different fix that should also work. I'm not sure why your code is still trying to add the sort by relevance clause, but it shouldn't be.
As for RLIKE returning more results, more results than what? FULLTEXT wouldn't have given you any results searching for 'TR1', and all of those other terms should also match. Is that an issue?
-
I'll look into the $order_string issue, but I've also just created a PR to allow the admin to choose the default search mode, a setting that probably should have been configurable all along. This will allow you to swap between fulltext, like, or rlike from the admin panel.
See my fix here.
-
Your search code is generating invalid SQL queries - have you modified catalogue.class.php at all?
You may consider trying to update CubeCart to the latest version as well.
-
Sorry you're having issues - I don't know what the cause could be, but there are some things you can try:
- If you have a backup of your database data, I would try a fresh install.
- If you don't have a backup of your data but can make one (e.g. via cPanel), do so and then do a clean install
After importing your data, you may need to run the .sql upgrade scripts from 6.1.2+ manually, either from PhpMyAdmin or via CubeCart's admin panel.
-
I agree it would be nice to be able to sort the home page in some other way, for example being able to choose between 'Last Added', 'Last Updated', and perhaps some others like 'Random', 'Featured' (which would additionally sort by last updated or random), 'On Sale' (would also need an additional sort qualifier).
I find it hard to imagine actually using any of the other fields to sort by, however - at least if you have more than a handful of products. Sorting by Name, Price, etc. is something that makes sense within a category or search result, but not really for the front page.
I also agree it could be made more clear in the admin settings what, exactly, each setting effects. To be fair, though, the 'Latest Products' settings are in their own sub-section - it's just not obvious that the previous section's settings don't apply.
-
There were actually several commits (in addition to those previously mentioned) related to fixing the search function:
https://github.com/cubecart/v6/pull/1408/files
https://github.com/cubecart/v6/pull/1415/files
Some relevant commentary:
https://github.com/cubecart/v6/issues/821#issuecomment-268098207
However, as @Dirty Butter points out, the 'Latest Products' sort order is by date added - the sort order in the admin settings is used when displaying categories, not for latest products.
Unable to checkout as guest with Invisible ReCAPTCHA
in Technical Help
Posted · Edited by bsandall
Tried deleting the session cookie as well, FF still won't even show the reCAPTCHA sidebar tab with the terms and privacy policy links. Basically, I am unable to do anything on the store front as a customer would when using FF with invisible reCAPTCHA enabled.
In Chrome, the invisible reCAPTCHA works for everything but checking out as a guest, as described in the original post.
I'm using the latest versions of both FF and Chrome. Not sure if this is a bug in the browsers, with Google's invisible reCAPTCHA, with CubeCart, some combination of those, or if it really is just a caching issue. If it is a caching issue, it's a pretty serious one that I imagine will also affect many of our customers.
@Dirty Butter I'm curious to hear the results of your further testing. You said that it was working in FF, but now it isn't... that's exactly what I experienced. Would you be willing to also try using Chrome?
That makes sense, but I'm not getting challenged at all during the checkout process. Instead, when I click continue, I simply get the 'The verification code was incorrect' error message indicating that reCAPTCHA couldn't verify I was human, and after that for some reason no matter what email address I enter in the form, after clicking continue again it tells me the email address is invalid.
I realize that reCAPTCHA does not validate email addresses - I'm just describing the symptoms that I am experiencing, both in Chrome and FF.
Note that the process works fine, at least in Chrome, so long as I choose to create an account during the checkout process.