dynambee

You give one example, I have another example: Amazon.ca. When Amazon is doing something to make it absolutely clear that they are pricing in CAD and not USD you can be sure that there is consumer confusion going on. Lots of Canadians are accustomed to seeing online prices in USD so it's important to make it crystal clear when CAD is being used. (I love looking at what Amazon does and then finding ways to emulate it. They're the undisputed king of eCommerce and they don't do things for random reasons.) Unless everyone who visits your site already knows your business (ie you're selling to a community where everyone knows you) there will be customers who are unsure if you are pricing your goods in USD or CAD and they will just assume that as you don't specify otherwise that you must be charging USD. It's always safer to assume the higher price rather than get a surprised credit card bill, and that will cost you business. I have plans to launch a Canada-focused site later this year, priced in CAD. I want to advertise that fact so people know they aren't going to get screwed on exchange rates and end up paying much more than they planned. I will certainly be leaving the CAD marks on all prices.

I would certainly love to see this! Anything to cut down on spam while not requiring real users to do anything extra is a win in my book.

I don't think it's necessarily a bad thing to have the CA part there. Many Canadians are very used to having to pay in USD online so depending on the type(s) of products you sell it might make your pricing easier to understand. Especially these days with the poor USDCAD rate potential customers are probably going to be very happy to not have to pay that 35% rate difference.

@Traumflug said in Let's talk about Search!: Works nicely and with decent speed from Germany. These pictures in the immediate search result are certainly a good idea! Thanks for the feedback! I'll be able to keep the dev box open for bradsearch testing for another day or so and would certainly appreciate more feedback & thoughts if anyone has a moment to try it. Sometime tomorrow I hope to be back to testing webservice stuff and will have to put the website back into maintenance mode.

@ssimard said in Let's talk about Search!: I have yet to test with all my products added but should be able to do it soon. (1000 books with their pdf and epub variants so close to 3000 products) I should also have a site with ~1500 products soonish. A few more things to prepare before I can remove the existing products from the site and start sending my actual products through the webservice. I'll be sure to try out bradsearch again at that time and see how it performs with more items, as well as if it needs a more powerful server to work. Hopefully speed can stay decent but I’m a bit worried at the moment… I think you should be okay with ~3000 SKUs. The website for bradsearch has some performance stats in a basic chart and their tests show 480ms for standard search results with 10,000 SKUs, vs 170ms for bradsearch. No idea what sort of hardware they were testing on, unfortunately. Things really start to go haywire at 100,000 SKUs and will go downhill dramatically from there. It will of course also depend on how busy your site is, busier sites will benefit more from a dedicated search system.

I have just "enabled" my dev domain so people here can try bradsearch. Notes: The server is in Tokyo because I'm in Osaka and it's really just for my own dev & testing. I have Cloudflare set up but I have no idea what the performance will be like in other parts of the world. I'd be interested in hearing how it feels speedwise, both for page loading times and for the search. (I am working with webservice integration right now so the site itself is bog standard.) The search box at the top of the display with the blue search button is the standard search. This has not been changed by bradsearch at all. The search box just below that with the black button is the bradsearch box. There are only the standard 7 products on the site right now so this isn't a proper performance test, just a proof of concept. Good test terms will be things like "dress", "summer", etc. Stuff that will turn up the standard sample products. Try with spelling mistakes too, in the bradsearch box. This is a dev box. Dual cores, 2GB memory. Not exactly a fast machine and far from an ideal Elasticsearch system. Please play nicely. :) The domain is https://inxonline.com/ Edit: I'll be able to keep the site enabled for a day or so, after that I will have to put it back into maintenance mode for further internal dev work & testing.

Hmm, interesting about the "instant search" feature with standard search function. I type pretty quickly (~120wpm when I was young, ~80wpm today) and I actually finished typing search terms and hit enter to search before anything came up. When I do the same thing in the bradsearch box the results start to appear nearly instantly and then continue to be refined very quickly as I continue to add letters and words. I have the minimum search length set to 3 characters on my dev box and by the time I strike the fourth key the results are there. So the feature is there with the standard search, it's just not all that...instant.

Thanks for the replies and the information! It's good to know that I (probably) wasn't doing something stupid that resulted in the missing filters. Many of the Brad files include a "you can do what you want with this" type of pseudo-license message. I'm not sure why they didn't just go with a known license that would accomplish the same thing while making things clearer for everyone. Perhaps they'll do this if asked about it... Invertus seems to be heavily wedded to PS and I'm sure they are feeling the pain of 1.7 as well. They might end up being quite interested in TB as a better solution for their own clients. The below text is causing a lot of confusion so I have edited it with strikethrough. Elasticsearch for a normal web store does not need anywhere near 8GB. If you have a busy site then you may find a separate server helps but for many sites it will be very possible to run ES on the same server as your web & database are already running. I fully intend to test this as I get sites operational and will add information here as I figure more things out. ~~That's interesting about the Elasticsearch memory requirements, I wasn't aware that it was that intensive. Looking at the Elasticsearch site it seems they recommend Elasticsearch servers have at least 8GB but not more than 64GB, and they do mention it's very memory intensive.~~ ~~My first goal is to get a site up and running, and then I will work on Brad and see what it can do with an 8GB or 16GB server and a few websites. Algolia is definitely interesting, if it is a big enough time saver without costing too much then it would be the better choice.~~

I'm definitely going to give it a try and see how it goes. I use Imagemagick extensively in my automated workflow for resizing & watermarking images, very happy to see it on TB as well!

The standard search functions of most shopping carts are pretty disappointing. I haven't looked into this in fine detail with TB but my expectation & understanding is that TB 1.0.x search is the same as PS 1.6 search, and as such it's slow and overall just not very good. No "instant search" with results as users type. No "fuzzy search" that gives results even if the user makes spelling error(s). No ability to filter searches by price / category / brand / supplier / attributes / etc. Worst of all is that the results themselves don't seem to be particularly good and as you add more products to a store it takes a lot longer for searches to return results. If the site is at all busy and has a higher number of SKUs then standard search will grind to a halt completely. Understandably all of this is very frustrating for visitors and frustrated visitors are less likely to convert into customers. So, what to do? There are some incredibly powerful yet rather pricey options out there such as Algolia hosted cloud search. @lesley has a very slick Algolia module available and this is, IMO, the best PS/TB solution for those who have the budget. Unfortunately I fall into the group of people with no monthly budget for search services so I've been looking into free high performance search options that are compatible with TB. A while back I came across a potential solution that I think might be of interest to other TB users: Elasticsearch + Brad. Elasticsearch is a free high performance full-text search engine that is used by some of the largest & busiest sites online. Facebook, Wikipedia, Netflix, GitHub, eBay, and the New York Times all use Elasticsearch to power their indexing & searching. Brad is a free module for PS 1.6 that enables searching through Elasticsearch on a PS 1.6 website. Brad has been around for a while and is currently at version 2.1. I installed Brad on a TB development server (a Cloudways VULTR server) that has Elasticsearch 2.4.4 running and Brad seems to work with TB -- mostly. There are some things I haven't figured out yet and I'm not sure if these are caused by differences between PS and TB or if I just don't have things working properly yet. What works out-of-the-box with Brad on TB: The module installs with no errors as long as you follow the directions on the GitHub download page. The back office seems to work fine. The Re-index buttons work and all the settings I tried can be adjusted and saved. In the left hand column of the back office there are various menu choices for Brad when looking at the module configuration. Settings, Advanced Settings, Filters, Filter templates, Info. These all seem to work as well and changes made are saved correctly. Searching for items. Once Brad is turned on searching is an entirely different experience. Results start to appear as the visitor types their search terms (this can be turned off in the BO if desired.) Type "sumer" instead of "summer" and you still get good results. Other spelling errors also usually still produce quite good results. Search results are fast, but it's difficult to gauge speeds on a dev site with few items. What seems a little wonky: My dev site is using the standard TB theme. The standard TB theme search box at the top, to the right of the logo, doesn't change to a Bradsearch box. Instead a new search box appears just below the logo. This is likely due to a difference in hooks or ID, something like that. I'll look into it but I'm not a web developer so my abilities are limited. Brad supports search filters out of the box but I can't get them to appear in TB. I'm guessing this is similar to the above issue and is caused by template differences but it could equally be something I'm doing wrong. While this system isn't completely plug-and-play at this point it improves the standard search even without the filters working properly. I will continue to monkey around with Brad in the hopes that I can figure out what is going on with the extra search box and the missing filters. I would be most appreciative if any other interested parties could do likewise. Perhaps working together we can figure things out and have a fantastic free search solution for TB!

My current server runs ImageMagick 6.8.9-9 which by default is not secure. However the recommended changes to the ImageMagick policy.xml file have been made which, according to ImageMagick and a bunch of security sites, make earlier versions secure & safe to use. (I have asked the host to upgrade the package but I'm not sure if they will.) So my question is can I use the ImageMagick module with the following packages installed on the host: PHP imagick extension 3.4.3 ImageMagick 6.8.9-9 (with recommended policy.xml changes) PHP 7.0 thirty bees 1.0.0 I'm happy to give it a try and see what happens but any thoughts in advance would be appreciated.

@Vegaanders, did you try clearing Cloudflare's cache for your site? You can clear individual files or you can wipe the entire cache. Probably best to wipe the entire cache. My guess is there is a conflict of some sort between what is in the Cloudflare cache and what your site is serving or expecting.

While it's definitely not my decision what goes in docs and what doesn't I would say this is more of a forum discussion topic than a docs topic. Different people have different needs, goals, and budgets so there will be some services that will better suit some people than others.

You do it through their page rules. You can do all sorts of things through page rules, but only if the cloudflare caching is turned on. Otherwise they are just providing DNS services for your existing host and DNS doesn't allow anything like page rules to work.

You can try clearing the Cloudflare cache to see if that helps. Also make sure you don't have page rules set up in such a way that it's creating a redirect loop or some other problem.

I'm running standard TB 1.0.0 on Cloudways using Cloudflare. I have Let's Encrypt HTTPS certs installed and both TB and Cloudflare set to force HTTPS everywhere. If you aren't using an HTTPS link to log in, perhaps try that? Or maybe you don't have a cert installed but inadvertently turned on the "HTTPS for all pages" feature in TB?

I'm running the latest version of Chrome, 58.0.3029.81 (64-bit) on Win10 x64 and have no troubles logging out and in to multiple TB sites I am using for development work.

It's also going to depend on how often you expect to be unavailable and how much it would cost you to be down for a period of time, assuming the worst should happen. Although I suggested Shopify above, it's certainly not a perfect platform. If you need extra features most of them are monthly subscriptions which adds to your monthly cost. If you need a bunch of them it can result in things getting quite pricey, especially if you have multiple websites. Shopify is also pretty inflexible with their shipping options which can be an issue for some businesses. If it is going to cost you thousands of dollars per day in lost sales then clearly having some sort of emergency plan in place is going to be a good idea. However if it's going to cost you a few hundred dollars in lost sales to be down for a week, it's not likely going to be worth the cost to have any sort of emergency system in place if you go away a few weekends per year. In the end only you can make this calculation for your specific scenario.

I'm not sure what @Random is using but I know here in Japan there are various non-instant payment options that likely work the way he describes. For example it's possible for people to pay for purchases at convenience stores. After checkout the site emails a code to enter into a terminal at the convenience store, the terminal prints out a slip, and the customer goes to the register and pays. Credit cards are much more common here than they used to be but there are still a LOT of people who don't use them online or don't have them at all. Convenience stores are everywhere and this system works well. Customer might pay a few hours or even a day or two later. Bank transfer payments are also common here and there are systems set up to make this much more automatic. Each transaction can be assigned a different bank account number to pay into so the system can tell which invoice has been paid. So there are definitely modern systems in advanced economies that don't have instant payment verification.

What do you mean by "emergencies"? If you mean customer service issues then having staff is the only option. If you mean having the web site taken care of while you are a way then the cheapest thing for you to do will be to use something like Shopify instead of something you have to support yourself. If you're in the US you can use Shopify Payments and then a Shopify store will only cost you $29 to $79 per month. It's not as flexible as TB of course but that will be the cheapest way to go. If you want to use TB and have it supported there will be options out there but you will certainly pay more than $29 or even $79 per month for such service.

I use Cloudflare and I love Cloudflare. Why? There's a free option! Obviously it's not as feature rich as the paid versions but hey, it's free! It works well too. Distributed DNS. This is a huge plus in my book. They have DNS servers all over the globe that will automatically have your DNS data in them. Fast DNS lookups are one factor in attaining faster first page loads. If you're using Cloudflare then you are also using their DNS. Their page rules are powerful, flexible, and not difficult to learn. You can use them to force https, do page redirects, exempt certain areas of your site from Cloudflare's cache, etc. There are no traffic limits or data transfer fees. Free is free and unlimited. $20/month for their business plan, also unlimited. They have CDN servers all over the world, more than other (affordable) CDNs I have checked out. It's entirely automatic. Once you have turned it on it just works. You don't need to upload data to them or manage the cache in any way. You can cloak your IP if all your domains and subdomains use the Cloudflare cache. This makes it quite a lot harder for an attacker to take down your domain. Cloudflare has DDoS protection that works quite well and will generally keep your server up and running if you do end up under DDoS attack. There are a few downsides to Cloudflare as well, though for me personally these are not serious problems: The first time your site is accessed via a Cloudflare node there will be little performance increase. This is because the cache is built dynamically as users use your site. This is the downside to #6 in the benefits. If some parts of your site are rarely used they may also not be cached by Cloudflare. They don't talk about how their caching system works but as more people in a given geographic area use your site the performance will get better as Cloudflare caches more and more of your site. All accesses to your site will come through Cloudflare, nothing will be directly to your IP from the end user. This means that your logs will all show Cloudflare IPs instead of the end user IP. Cloudflare has a workaround for this and many webhosts have options to make this work for Cloudflare users. I host on Cloudways and in their control panel they have an option to work with the way Cloudflare forwards the actual user's IP. It works flawlessly once set up. Cloudflare serves cookies with all content. There is no way to disable this at the current time, AFAIK. This will come up in all performance testers telling you that for static content you should serve it cookieless. I haven't looked into why Cloudflare does this or if they have plans to change how they do this in the future. Overall I think Cloudflare presents an incredible value, either with their free plan or with their $20/month business plan. It's easy to set up and is in my experience an effective CDN and DNS service.

There are pluses and minuses to a system like Shopify. Minuses that I came across when considering Shopify: If you are outside the short list of supported countries (United States, Puerto Rico, Canada, the United Kingdom, Ireland, and Australia) then you can't use "Shopify Payments" (seems to be rebadged Stripe) so you have to pay transaction fees which get very expensive very quickly. They don't offer calculated shipping options unless you choose their $300/month (wtf?) option. The shipping options they do offer are not very flexible and it may not be suitable for people in countries that Shopify doesn't serve specifically. Many Shopify plugins/addons are monthly subscriptions rather than one-time purchases. This is attractive to developers I am sure but as a shop owner it quickly jacks up the monthly cost if you need a few extra features in your store You have no direct access to your database. I haven't looked into this recently but in the past that meant no bulk updates or custom updates, you have to update items one at a time via the API. No problem if you have 1000 SKUs, huge problem if you have 10,000 SKUs, impossible if you have 100,000 SKUs. If you want to have multiple stores then you get to pay their monthly fees for each store, and of course monthly subscriptions for all addons for each store. $$$$ Pluses that I came across when considering Shopify: Their site designer is nice and their included free themes were high quality. Their API is very complete and seems to work well (as long as you don't need bulk updates, but maybe this has changed it's been some time since I last looked.) It's a complete package including CDN and everything complicated like caching is managed for you. This will result in far better performance than any unskilled person can expect when setting up their own cart. Shopify stores tend to be fast to load and nice to use for customers From memory their back end was nice to use for the store operator. Good built in SEO, as long as the user populates the necessary fields as they set up their store. No need to worry about type/performance of hosting, something that can be daunting for non-technical people No need to worry about updates or security patching as this is entirely managed by Shopify No need to worry about compatibility of add-ons with cart versions as this is managed by Shopify Of the "pay us a bunch of money per month" options out there I think Shopify is the best available. For anyone non-technical running a single site in a country that supports Shopify Payments it is, IMO, their best option. If you don't need any addons and don't care about abandoned carts it's only $29 a month. If you're in a country where Shopify Payments isn't an option then it may still be the best choice if your market segment isn't super competitive and you can afford the additional 1% or 2% transaction fees. If you want a system you can scale to multiple stores and you don't mind figuring things out yourself then going with Thirty Bees or a similar cart will be a much better option, especially over the longer term. Edit: Added a few more "pluses" to the list.

Cloudways allows you to create "team members" that you can limit to specific servers and/or to specific applications within that server. So if you have a client that has two TB sites that you are hosting for them you can limit their access to just those two TB applications. You can also give employees within your own business their own access credentials and decide how much control they have over your Cloudways account. It's not really designed as a reseller system though as all "team members" long in through the Cloudways platform itself so they are going to know where & how you are hosting their sites.

The Hostgator purchase is old news, but should it affect Hosteurope performance I would be the first to leave. The purchase of HEG by GoDaddy (not HostGator) was announced a few months ago but was only finalized a few days ago. If changes are coming they will probably take a bit more time to appear, sometime later this year seems likely. If I was a customer I'd certainly be a lot happier to be acquired by LiquidWeb (like WiredTree was in January) than to be acquired by GoDaddy. About Redis. I dont know if it can be called configuration, but you still have to choose to use cache AND choose redis as the system I see what you mean. I hadn't actually tried this yet, but yes, caching must be turned on, saved, and then Redis selected and saved. I'll edit my posts above to reflect this, as the point of this thread is supposed to be how to get the best performance out of TB.

One can debate hosting all day, so I think we'll have to agree to disagree. You may find it interesting that GoDaddy just bought HEG though. In the end if HostEurope meets your needs then they're the right host for you. As far as Redis, @lesley (one of the people who helped set up TB) stated on the PS forums that no additional configuration is necessary when using TB on CW. Turn on Redis and it works. You can see the post here: https://www.prestashop.com/forums/topic/597927-who-has-the-fastest-ps-site/?p=2537438 Edit: Caching must be turned on in the TB back office (Advanced Parameters --> Performance), saved, and then Redis selected as the cache type, and then saved again.