moy2010

@MockoB said in Tutorial: How to migrate from ps 1.6 to thirty bees: I'm on 50mb fiber optic internet and constantly watching movies with Kodi on my tv box in 1080p so I doubt it is the reason :) There's a chrome widget that auto sets Youtube to the highest quality. If you use this browser, I totally recommend it.

@Havouza said in Let's talk about Search!: So how to calculate what you need. The only way to calculate how much RAM you need is by measuring it. I'm not planning to sound sarcastic, so please don't read it that way. This sentence is repeated in ES forums like a mantra, and I fell into thinking that they were being sarcastic, too. What the members in the ES community mean is that, due to its nature, ES can be used on a huge plethora of scenarios that range from analytics and logging to searching, among many others. This case is worth mentioning: https://www.noschoolviolence.org/ They use ES to identify behavioral patterns in students, so they can intervene early. This is one of the reasons for why there's no right answer to the question: "How many resources will ElasticSearch use?" You have to measure it in your very own ecosystem, every single time. Now, back to our eCommerce interests, I'm currently using PrestaWach's ElasticSearch Connector, and my RAM consumption for ES is ~130MB for autocomplete and full-text search in production with ~5000 products. I'm yet to measure the resources consumption for ES being used in many other scenarios, but so far so good :).

These errors will affect other PS modules that deal with URLs aswell, @mdekker.

Sure. Hope this quick explanation suffices: Nginx cache/Varninish cache = ProxyServer Cache. This caches all HTTP responses (200, 302) when a GET request is sent. Redis cache = Database Cache in RAM. Normally, your database caches using the filesystem cache; but with Redis, you load everything database-related to RAM. Smarty cache. It caches the html code, that results of the compilation of your smarty templates. Full page cache. It caches the current page html. OPCache. It caches the compiled PHP code. Browser cache. It caches the requested data (images, css, js, html, etc.) in local storage (client). If you understand the flow of page rendering, you'll know which cache works in what step. What are the risks? Well, there are just way too many risks. For example, you wouldn't want to cache a PUT or POST request, data with cookies, or a dynamic webpage that changes on every render, it would be a waste of resources.

@dynambee I have ~5000 products, and my statement was very clear: "I need something as good as ElasticSearch connector for prestashop, but that covers faceting search and a custom autocomplete search". We have been working on this for about a year, and it's almost ready at this precise moment :). Just some minor tuning and it'll be ready to hit production by mid august!

@Briljander No. If you use it for text-search only, I highly doubt you'll need more than 256MB of RAM.

For the quality of the code anf its functionality, it's been worth every penny since I purchased it two years ago. The developer is actually helping me with our custom ElasticSearch implementation, because he does know what he's doing :).

That's the best module for ElasticSearch in Prestashop, for sure.

It is in some points, but true in some others. We could read it like this: "If you pay, Algolia does everything for you" :P

A comparison between Algolia Search and ElasticSearch from Algolia's blog: https://blog.algolia.com/algolia-v-elasticsearch-latency/

The problem with default ecommerce software search is that it suffers from performance issues, because it's not suited for big shops with thousands of products. Once merchants realice this, they will definitely look for something better (and might another way to attract users to 30bs, @lesley @mdekker ). I would really like to get a module named "Thirtybees Advanced Search" that would, once and for all, solve the issues with faceted and text search from Prestashop. We all know the horror stories about PS Layered, right? Now, IMHO when users are in such a situation where the standard search is no longer enough and start looking somewhere else for solutions, soon realice that BRAD is that it's a very basic implementation and requires a lot of tweaking. Just to quote dynambee's issues: @dynambee said in Let's talk about Search!: A few points about BRAD that I have noticed from testing without fuzzy search turned on: * BRAD (without fuzzy search) seems to be an exact phrase search. If I search for duel hardcore I get great results. However if I search for hardcore duel I get nothing. I expect this is a problem with the way BRAD has been coded. * The thumbnails that appear in the instant search results are supposed to appear to the left of the search results. For some reason the box isn't wide enough right now so they are appearing on a separate line. I'll try to fix this as it looks much nicer when it's all on one line. * I'm very much a keyboard guy (I guess most programmers are?) and when I get drop-down instant results like BRAD provides I want to be able to hit the down arrow to move down and then select a result by hitting ENTER. The standard 30bz search does this but right now BRAD does not. I hope that Thirtybees' Advanced Search will get these cases solved!

Indeed. The simpler, the better. Most users will value the simplicity of the settings but, leaving open the option to customize it for the rest of us :).

Afaik, only with paid modules

Try with the keys combination "CTRL + F5" to force a browser's cache refresh.

Hum, I'm facing this same issue after migrating from prestashop to thirtybees. I recognize that it may be helpful to automatically set the currency format based on the customer's location as in your example of the euro zones but, sometimes this will not be the case. Wouldn't it be better to let the user decide if this will be set automatically or manually, just as the other language/zone related parameters?

Onsite search is much more complex than most users realise and, to be honest, thirtybees default search is good enough for like 99.9% of merchants. Though going beyond that would be welcome, I don't know if it's the right time to do so (I think there are some more important subjets for thirtybees developers). In the meantime, we can discuss search and how would you like to get integrated into an ecommerce platform :).

1.0.0 :)

The form fields that appear are insufficient to add a new address. These are the fields that appear: Customer Identification Number Address alias Other

Hi, Rickman. Are you copying the theme's files from the FTP or from the .zip file provided by the theme developer?

Did you enable the clean URLs option, @Andrey ?

You have to merge both overrides in the override folder.

Nope, in PS there's only a warning when you exceed it, but it's not stated anywhere. I think it's around 250 char.

@mdekker let us know once the project is on CrowIn. I can help with the spanish translation.

Yep, I can vote now.

@musicmaster said in Product and combination types missing in Prestashop: Some attributes are in fact separate products. They might be considered as accessories but you want to sell them on the same page. The car radio is a good example. This kind of attributes comes in two varieties: some are also sold as standalone products while others are only sold as a part. It's worth mentioning that the packages of separate products need to track the price also. The relation between "fields" or "attributes" in the combinations system must a "many to many" one, instead of the "one to one" way that the PS team thought it to be. We must be able to select hoy many of every single group of attributes is necessary to proceed, so we can get options such as: Buy X, select one of Y. Buy X, select two of Y. And so on. We may even be able to make packs of not pre-selected products: Select one of X, then select one of Y. Select one of X, then select two of Y. And so on. I've read that some efforts are being done right now to improve the checkout workflow, so that it doesn't require unnecessary steps such as JS+AJAX+PHP+JSON+SQL... If the checkout workflow is cleaned of the logic impossed by PS, I believe that the performance improvements might be sufficient to get a robust combinations solution. Other attributes concern things that never get out of stock. If you sell furniture you may offer it in different colors. But as you paint them yourself and you have an ample supply of paint this will never be a restricting factor. In this category fall also work-related attributes like when you sell a product in a rude and a polished version – the latter involving some processing by you. Then there are the products that don’t fit. One category are the “fractions”: products sold by meter or gram or other linear unit. Say you sell cheese for 10 euro a kilo. You have a piece of 485 gram and you would like to receive 4.85 euro for it. The only way to achieve that would be to set the price per gram. But that would mean that you list it as 0.01 euro per gram. That will result in rounding errors and it goes also against industry practices that dictate listing prices per 100, 500 or 1000 gram. Also it doesn’t give the customer a quick impression of whether the product is cheap or expensive. Having a system of UoM (Units of measure) might solve this. If we set the product's standard UoM to Kg., then selling it in an equivalent UoM such as grams would not be an issue. This system of UoM and equivalencies could even be embedded into the attributes system by having an "attribute type" field with the following possible values: Separate Product (Which would require an input field to select the product to be treated as an attribute) Unit of Measure (With Name and equivalency -in case that this is a new UoM- fields) Modification or Virtual (For attributes that don't need stock tracking per se, but may or may not have an impact on the price) Another category are the “standalones”. These are a kind of customizations where you want to set the price. It might involve work. If you sell floor coverings you typically bill carpets and work to install it. But you don’t want to make a new “work” product for every new customer. I sell fancy boxes that can be filled with candy. I would love to give the customers the freedom to choose which candy they want in it but that is impossible under Prestashop. Candy sells by weight and different types of candy have different weights per liter. It would be easy to write some custom software that calculates the correct weight and price but I can’t store it at the moment. So what are the possible solutions? In the case of the attribute combinations my favorite would be to allow more than one product on a page. They should be in the same html form so that you can order them with the same Buy button. This means that you will need to mention somewhere the number of different products on your page and give them numbers to discern them. You need also to indicate which is the main product and which are the options. For attributes that don’t affect stock there are two possibilities. You might create a new kind of attribute for that. You could also create a kind of pseudo accessories for them. You might for example have a “product” colors that cannot be sold alone for this purpose. It is a rather convoluted solution but it may be easier to implement than a new kind of attribute. In the case of the fractions the cleanest solution is probably to indicate somewhere that your price is per 100 units (or whatever number you want). In the case of the standalones the basic point is that there is no standard price and that the shop owner must somehow provide a price. In addition, it's worth mentioning that this logic has to consider not only how we sell products, but also how we do purchase them. If we sell cheese and allow our customers to purchase in grams, but we purchase them in units of 5 or 10 kilos we must give merchants the possibility to have different units for stock and sales. All in all, this is a wonderful post that might help in the features' roadmap of ThirtyBees :).