dynambee

Just for the record, Brad does offer faceted search (aka filtering of search results). The downsides to Brad are that the license is non-standard and that the back-office part does not offer detailed configuration of the module. The Polish-created Elasticsearch Connector module for PS has a finer level of control in the back office but doesn't offer faceted search and uses a slower way to search ES and then display results. It also does not have an option for displaying mini-thumbnails in the drop-down search results. There is a $250 ES module for Magento ($500 if you are using Magento Enterprise) that has quite a good front-office appearance. I haven't looked at their back office in detail and I don't know how the internals of their querying works. Their demo site is very underpowered and/or very heavily loaded (probably underpowered and shared by many demo sites for their modules, thus being also overloaded) and the entire demo site runs slowly, at least from Japan.

Perhaps once the community is more established we could consider doing some crowdfunded modules that would support 30bz. I don't think there is anyone in the community right now who is not part of Thirty Bees Inc who would be trusted by enough of the community to manage such a project just yet. Perhaps that will change over time.

Selling it would be against what we have said we are going to do as a company, I don’t think that is something we are going to do. I can see how it could create a potential conflict. However I believe what you have said is that 30bz won't sell their own in-house modules. As the development for these modules is being paid for by the community, if the community wants to use the modules to support 30bz shouldn't that be acceptable? Of course I make no claims to speak for the entire community (or anyone besides myself!) Many more people need to chime in with their thoughts on this.

@Havouza kindly shared a couple of interesting write-ups he came across in relation to search, and specifically the difference between using a database for search and using a proper search engine. They're written by a developer who worked on a large scale search system for a big ecommerce company but they are well written and I think many people who don't do development work will be able to grasp more of the important concepts: What Makes Search Engines Special? -- This one talks about search using standard database lookups for search, like PS and 30bz do now. Building a Search Engine for E-Commerce with Elasticsearch -- This one talks about using a search engine for eCommerce search, some of the issues he encountered on the project, and how different types of search queries can lead to very different results. Very worthwhile reading!

So this is what I am considering now, after the discussion in this thread: Create each fishing reel part as a separate product in 30bz. There will be ~100,000 to start, later potentially rising as high as 500,000. These will not be shown in search results or in the standard catalog. Create a dummy product for each fishing reel that we sell parts for. There will be about 1,100 of these dummy products at first, later potentially rising as high as 5,000 products. These will not be shown in search results but will be shown in the catalog. They will be in their own category sub-tree. Eventually I would like to create a custom search for just this subtree so customers can find their parts more easily. In our in-house software we will also create all these products and we will associate the "dummy product reels" with the parts for that reel. This will allow us to auto-generate the descriptions for the dummy products to be used on the 30bz site (and of course allow us to automate the upload all 100,000 parts and 1100 dummy products). These descriptions will consist of a list of parts, each with the number that matches the exploded parts diagram and the 2-3 word name for that part. There will also be a button to add the part to the shopping cart. The exploded parts diagram will be shown at the top of each of these pages for customer reference. We will use @lesley's “Flex Layout Module” to apply a custom layout to these pages. I'll probably pay someone (perhaps @lesley if he has time, is interested, and if I can afford his time!) to create a responsive page layout for these products. The layout will have to remove things like the main "add to cart" button for the dummy product, the "out of stock" message for the dummy product, etc. as well as display the products list in an attractive & easy to use way across devices. Does this seem like a reasonable solution?

I have another idea for the license & copyright that might be interesting, though unusual: Thirty Bees Inc owns the copyright and the license is not open source. Anyone who contributes at least 5% of the crowdsource goal gets a perpetual license (including upgrades) for the project's module to use on one website. Anyone who contributes at least 10% of the crowdsource goal gets a perpetual license (including upgrades) for the project's module to use on an unlimited number of their own sites, but not to resell or include with projects that are sold. If a project is extraordinarily expensive for some reason then these amounts could be lowered or even changed to a fixed amount instead of a percentage. The goal is to encourage people to donate by giving them a benefit that isn't available to non-donators and if the amount required is too high then people won't be able to afford to donate or it won't be financially justifiable. When the 30bz Addon Store goes live (hopefully soon! :)) the module is sold in the store for, say, 100 Euro. Some modules will be more expensive of course, some may be cheaper. 50% of the sale price goes to Thirty Bees Inc. The remaining 50% is used to fund things like: New modules that follow the same path (fund up to 50% of the cost so people can contribute as well) New features for existing modules developed under this program. Upgrading modules developed under this program to maintain 30bz compatibility as the core develops and changes. Possibly used for other things such as to develop high quality themes to include with the 30bz core. . Usage of the funds would be voted on by the community. In the first round of votes all potential options are shown. If no single option gets more than 50% of votes then the two most popular options should have a runoff vote to make sure the winning choice has the support of at least 50% of voters. If it ends up that there is too much money in the pot with no good way to spend it then the selling price of the already-created modules should be lowered. Modules should not become completely free however, but the price could get quite low if necessary. If more funds are needed later then the prices can be increased again. I think there should be an agreement that if 30bz is sold to a competitor or shuts down that the modules in their form at that time should be released as open source. Likewise if the crowdfund project is ever abandoned completely then the modules should be released as open source. There are, of course, some potential problems with this model. One is that the community would be trusting the company to follow the rules. I'm a trusting guy and see no reason not to trust @lesley and @mdekker but I can also understand that some people may not be as trusting. I don't really see a way to do this easily without trust though. The second big problem is taxes. If the money is not spent within the tax year then it's going to be seen as profit for the company and the company will be taxed. ~~The only way to avoid this problem would be for a separate legal entity to be created as a non-profit to hold these funds. This would have overhead as well, which would have to be covered by the income from the sale of the modules created. I don't think this has to be dealt with right away, we'd actually have to see income & profit from sales before having to worry about this aspect. Still, it is something to consider and be aware of.~~ Edit: Thinking about this more it seems unlikely that a non-profit could hold funds that would be later used to generate income for a profit making business. I suspect the IRS would view this as tax fraud, but I'm not a tax accountant nor am I tax lawyer. If this is going to be a problem then tax will have to be paid on the balance and the balance would be lowered. Best to keep projects rolling and thus avoid losing funds to the gov't. More modules for the platform! :) Likewise there are some big benefits to this model. For now 30bz and PS are very similar. If the modules our community funds are released as open source they could be relatively easily adapted to use on PS and then put on the PS store as a free module. This is the way open source works of course and it's not generally a bad thing. However from my perspective one of the big reasons for doing this crowdsourcing at all is to support 30bz and encourage it's growth as a platform. It would be quite disappointing (for me, anyway) to see our crowdsourced modules sold on the PS store. This is one big reason to not use an open source license. Another big benefit is that the sale of these modules would support Thirty Bees Inc. As we all know, if 30bz doesn't make money then it will collapse. That would be really bad for all of us so anything we can do to help avoid it happening would be great. Finally I see another big benefit to doing things this way and that is to encourage contributions to the crowdfund project. On the blog post discussion thread a user pointed out that without benefits to the contributors it will be hard to attract people to contribute to the project. Maybe people will contribute to the 1st project, but what about the 2nd? The 10th? If not contributing gives the same benefits as contributing far fewer people will contribute. This solves that problem very nicely.

@Havouza said in Community theme update: but if I copy the theme folder, rename it and upload it again as another theme? Will that work @lesley said in Community theme update: You would need to create a new installer for the theme, but that could work. Wouldn't this work? Create a copy of the theme folder with a new folder name. Go to the back office (Preferences --> Themes) and choose "add a new theme" Choose "Create a new theme" Give the new theme a name and set the theme directory name to be the what was created in #1 above. I think this is how it was done in PS 1.6, no? Did something change?

Nope, I haven't installed Piwik yet so I don't really know much about it except I really like the idea of having my own analytics server. I think Google Analytics is blocked by many adblockers, right? Adblock is getting smarter and smarter but I would imagine self-hosted analytics is harder to block than something like Google.

Nice find, I've downloaded it and will have a read. I didn't realize there was a professional (aka paid) version of Piwik as well as the free one. It seems to offer a lot more features but I bet it costs a bundle. Any company that doesn't publish their prices generally charges enough to make your eyes water, in my experience. Does anyone who knows Piwik well know if there are modules and addons to the community version that give it some of the pro-level goodness for free?

There are two main makers of reels in Japan, Shimano and Daiwa. With Daiwa we actually see their true unique internal part number for each part. We can build a cross-reference database for their parts and see exactly which parts are used in 50 different reels. With Shimano however they do not provide their true unique part number for each part. All we get is the reel's part number followed by a generally sequential number. So we send them an order for a Scorpion 200HG Star Drag we send them the part number of the reel (03225) followed by 016, like this: 03225-016. That 016 is the sequential number on the exploded parts diagram for this reel. There are four different reels in the Scorpion 200 series and they probably all use the same Star Drag but we have absolutely no way to know. :( To be consistent between the two brands, for ease of customer understanding, and for ease of automation we will list Shimano and Daiwa parts in the same way. This means even if a part might be shared by 20 different reels the part will be listed in the system 20 times, with the part number for each one being made up of the reel's part number followed by the parts diagram sequential number. We also have another problem: Shimano has about 600 currently produced reels but has parts available for about 1100 different reels. Those 500 discontinued reels (1100-600=500) won't be listed on our website but we will still need a way to sell those parts. This is why I thought the dummy product and listing parts on the dummy product's page might be a good way to make this work and be consistent.

@DavidP, thank you for your reply. One issue is that we wish to keep the parts separate from the actual products themselves. Many discontinued items still have parts available. The discontinued items don't exist on our site so we would then have to have a different way to list parts for those items. To keep things simple and easy to automate I would like to list all parts using one system rather than have a few different systems to manage. The other issue is that PS (and thus 30bz for now) has the reputation of getting very slow if there are too many combinations on the site. I was't sure if this was actually correct or not but based on other replies in this thread it does seem that having 500,000 different combinations would kill the site's performance. So I think I will be listing each part as its own product on the website. I just need to figure out the best way to group all a reel's parts onto one page so customers can order what they need with ease.

I have suggestions in response to my own questions above: The code should be released under GPLv2 or GPLv3 The copyright should be jointly held by Thirty Bees LLC and the top 10 contributors to the project. Contributors would have the option to not accept copyright if they wish, in which case they would not receive the copyright and their name or company name would not appear in the copyright notice. \ Alternatively rather than the top 10, all contributors over a certain dollar amount who wish to receive copyright. The minimum amount should be low enough that multiple people will contribute the required amount but not so low that a single project ends up with 175 different copyright holders. 100 Euro sounds like a good number to me. The reason for #2 is that the owner of the copyright can choose to release the code under additional licenses if they want to. So if the code is under GPLv2 and the copyright owner decides to also release the same code as a proprietary product and sell it on the PS store, they could do this. There is nothing wrong with dual licensing and MySQL is a great example of a company that did this well. However for a community funded project being released as Free Software there should be some guarantee that the software will always remain Free Software. Assigning the copyright to multiple people makes it very likely that the software will forever remain under the GPL and GPL alone. The reason for this is that in order to change the license every single copyright holder must agree to the change. If even one copyright holder can not be found or does not agree to the change then no change can legally happen.

@moy2010 said in How to effectively list 100,000 parts on 30bz: Consider the following: You cannot handle stock quantities for attributes, nor to sell them separately. You'll have to handle the parts as products. The same goes for the prices. You can decide what will and will not be indexed with ES for search purposes. Definitely clear now that the individual parts need to be listed as separate products on the 30bz site. This works well for me as the way PS/30bz is set up it is easier to manage products than it is to manage variations. As for displaying the parts within a reel product page, there are several ways for achieving this. Many of the reels we sell parts for are no longer in production and as such won't have a product page on our website. With this in mind I would sooner have reel parts grouped by category and use custom category page layouts so customers can see the list of parts and quickly add them to their shopping cart. Here is a link to a reel parts page from one of my competitors: http://nullrefer.com/?http://bit.ly/2s94mrz (Please excuse the redirected & shortened link, I would sooner their logs not point back to this thread. ;)) Their site design leaves quite a lot to be desired but that is the general basic idea that I am considering. Of course what I want to do will be to make it look nicer and to be a responsive layout for mobile users too. Of course what I am thinking of does not have to be done as a category page and I would be very happy with other potential solutions too. One thing I have thought about but I suspect may be a PITA to implement would be to have a separate search for parts. When customers enter the "parts area" of the website they get a second search box where they can search for a reel to buy parts for it. One way I can think of to accomplish this would be to create a separate ES index just for the names of the parts categories (rather than the parts themselves.) Users could then proceed to the category of the reel they are interested in and find the right part from the exploded diagram and parts list. All parts categories would be contained within one sub tree of categories so it would be easy to index them. Another option would be to create "dummy products" in the tb_product database. This is a little difficult to describe well, but the idea would be that it's probably easier to index products than it is to index category names, as far as being able to use search in a standard way and without making modifications. \ So to use the same product linked to above on the competitor's site, I would create a dummy product called "15 Saltiga 4500". This product would have no stock and would use a custom page layout that removes things like "out of stock", "price", "add to cart", etc. Instead when a customer visits this product page they would see the zoomable parts diagram and a list of parts more nicely formatted than what is on the competitor's page. The customer can then add the needed parts to their cart and proceed with checkout. \ Another advantage to doing this is that the list of parts to include on the page could be stored statically for each product. This list can be generated by our automation system and stored in the product description area. The custom product page layout would then use this list of products to build the page with prices, add-to-cart buttons, etc. \ Anyway, these "dummy products" could be put in a separate "parts category" that is only searched from the "parts search" box. The regular site search box would ignore this category so that parts products results don't clutter up search. Overall I like the second idea as it allows for search without cluttering the entire site and it seems that overall it would require the least number of unusual hacks to make work. Any ideas? Is this total insanity? Having that many categories is not a problem, but I suggest to have a clear products taxonomy before launching the ecommerce store. Otherwise, you'll suffer much, much more. I.e., it's easier to decide which product categories will be indexed or queried for full text search. No problem, we have a well laid out category tree already existing. We would like a way for customers to be able to search for product parts but not if the results will clutter regular search results.

I've also been following the poll closely. Voting seems to have slowed down quite a bit and the overall balance seems to have stabilized with ES having around 50% of the votes. I'm surprised the Google Marketplace module didn't do better than it has. I hope we can fund that module at some point as well, I think it's a very important set of functions for many sites. I do have two questions, and one module feature request. Questions: What license will this module be released under? My preference, for what it's worth, would be one of the GNU General Public License versions. GPLv2 seems to be the most popular even today but either v2 or v3 would be fine. These are the licenses with the most assurance that the code will always be open source free software. Who will own the copyright for the module? I think this is especially important if the planned license is to be anything other than GNU GPL but regardless this should be clarified before the project is started. Feature request: The module should respect the 30bz Back Office "Visibility" setting. This setting currently has four options: Everywhere Catalog Only Search Only Nowhere Items set to "Everywhere" and "Search Only" should be indexed for search. Items set to "Catalog Only" or "Nowhere" should not be indexed for search or should be removed from the index if they are already there. These settings are saved in the tb_product table columns indexed and visibility. Any time indexed is set to 0 the item should not show up in search. If it has already been indexed it should be removed from the index. If it hasn't yet been indexed then it shouldn't be indexed. Any time indexed is set to 1 the item should show up in search. If it has't been indexed yet then it should be added to the index queue or added the next time a cron job runs, depending on how the shop owner has the module indexing options set.

@lesley, @moy2010, thank you very much for your kind assistance & knowledge. I'd heard that too many different attributes & combinations is bad for performance but i wasn't sure just how bad it might be. @lesley said in How to effectively list 100,000 parts on 30bz: Your only real option is to sell them as products. They are not an attribute of a product. Well that is definitely settled then! As far as the amount, yes, it can handle it, that is not to say you can handle it on a 2 core vps server, but a setup can be made to handle it. Would all these parts really place much load on the server? The parts will have no photos, no descriptions, very short names, a part number, and won't be indexed for search. All 500,000 parts items combined seem unlikely to add even 10MB to the database. I could easily be missing something here, even something obvious, so any information & ideas would be appreciated. I can show you how to bring back the scenes area which will allow for having schematics with links, but it is not responsive or zoomable, that would need to be custom written into the theme. Due to the number of products & parts I don't plan to do anything fancy. The system just needs to show the schematic image at the top and then all the parts listed numerically below it, probably in two columns. The parts diagrams are labelled numerically starting with 001 so sorting won't be big deal. Beside each part I'd like the customer to be able to choose the quantity to purchase and beside that an add-to-cart button. As far as excluding the products from search, that would take something custom as well. A module would need to be developed that overrode the search and limited the categories that it would index. Are items that are marked as "catalog only" in the back office still indexed for search? Looking at the tb_product database table, changing a product's visibility setting from "both" to "catalog only" changes two fields in the db: indexed changes from 1 to 0 and visibility changes from 'both' to 'catalog'. It is all possible though. Well I'm certainly going to make a site that will be both a test case and a future example!

Thank you for your reply and assistance. Do products share the parts? I mean, can the same part be found on more that 1 product? Well, yes and no. Yes, there are many parts shared between different reels. However the way the part numbers are provided to us, a dealer, it appears that each one is unique. So on 30bz each part will be unique and there will be no parts that appear in more than one reel. Will you need to handle stock quantities for the parts? Due to the extremely large variety of parts we do not stock these items -- no dealer in Japan does, actually. The manufacturer stocks them and ships them out when orders come in. The manufacturer is very good about keeping items in stock but really terrible about sharing exact stock information. Therefore we sell these items "blind" and explain this to customers. About 1% of orders can't be filled, in our experience. In this case the customer gets the option to wait until stock comes in or they can cancel their order and receive a refund. How will you calculate the stock for the products? We'll likely just set available stock to be "5" or "10" for each part and automatically reset it after we ship each order. This will be an automated process.

Thanks for your reply! The products are fishing reels. Each reel has somewhere between 50 and 200 parts. Some of the reels have been discontinued already but parts are still available. In this case we wouldn't be selling the reel itself, only the parts. In other cases we sell both the reel and the parts. Typical parts might be "spring", "bolt", "washer", "spool", "crank", "drag knob", "crank handle", "click pawl", "level wind", "electric motor", etc. There are about 1800 unique part names that we are currently translating from Japanese to English but there could be 100s of different parts with exactly the same name. Part numbers are of course unique. There is no problem managing the parts themselves as this will be automated, and there is no need for individual photos of the parts (which is good because I'd go insane trying to manage that...) The issue I face is finding the best way to present these parts to customers. Customers often buy multiple parts from one reel at the same time so having all the parts for one reel on one customer-facing page is important. Being able to quickly add different parts to the cart is important too. As far as the items we would like to appear in search this would basically be spools and maybe cranks. Spools in particular are things that people often buy for various reasons besides repairs. When someone searches for a given reel, seeing that they can also buy a spare spool is quite valuable to us. If using variations is a better solution than using categories then I can either list the spool as both a variation and then again as a separate product or it could just be a separate product and not listed as a part. I hope this helps clarify things. Happy to provide more details as needed, of course.

It might be helpful to @mdekker if you give links to the PS forum thread(s) with discussions about these bugs. More details might be there and more bug discussions might be there too.

Soon I will need to list ~100,000 parts on a 30bz site. This will be for ~1100 products that have ±100 parts each. If this goes well the number of parts will eventually reach about 500,000. I want to list all ~100 parts for one product on one page with an exploded parts diagram of that product (ideally zoomable) so customers can figure out what part they need to order. The parts themselves have no description, only a short name (1 to 3 words -- think "washer", "bolt", "spring retainer", etc) and a 10 digit part number. I do not want these 100,000 parts to appear in search results as it would make it impossible to find anything that isn't a part. That seems easy enough to do by setting "catalog only" for each part in the back office. I have come up with two possible solutions for this but I may be missing something and would like some feedback: Create a separate category for each product and put the ~100 parts for that product into that category. Then use @lesley's "Flex Layout Module" to enforce a custom layout for these category pages. This has an added benefit that there are a few key parts (1 or 2 per product) that we actually would like to appear in search results and this would allow us to do this. Use product attributes. Create a "parts product" for each product we sell parts for. ~1100 "parts products" at first, eventually perhaps up to 5000. Each of these "parts products" would contain a single attribute ("part type") with ~100 different options to choose from. Once again use @lesley's "Flex Layout Module" to design a custom layout for these products so instead of showing a huge dropdown list of 100 different choices it breaks them out onto the page itself with an "add to cart" button beside each attribute choice. I'm not sure if I am explaining the above properly and I'm also not sure if either option is even possible. My questions though: Assuming both options are actually possible is one better than the other? Is having 5000 categories a problem? How about having 5000 different products each with one product attribute containing 100 different options? Is it realistic to use custom layouts like I described above? Is there a better way to do this that I haven't considered? Help appreciated.

That's actually the same problem. The domain/address the email comes from (your server in this case) must match the domain the email address claims the mail is coming from (Gmail in your case.) This is checked by using SPF and DKIM to see if the server that sent the mail is authorized by the domain (Gmail in your case) in the email address. If it's not authorized you get errors like you saw or your message just gets sent to spam.

Hi everyone, I'm trying to get PS 1.5 sytle tabs to work in 30bz. @Nemo has a very helpful tutorial about how to do it with PS 1.6 but it involves editing the theme's product.tpl file and this file has been heavily rewritten in 30bz. Following @Nemo's tutorial a friend of mine (I suck completely at PHP) tried to correctly insert the PS 1.5 code into the 30bz product.tpl file, but the insertion points @Nemo mentioned were often not there so the code is likely in the wrong place. After hacking around with it for a bit I renamed the original file on a brand new 30bz 1.0.1 installation and uploaded the hacked together product.tpl. The result is this: https://www.zila.jp/index.php?id_product=1&controller=product If that looks exactly like a normal product page, you're right. Making the changes with PS 1.5 code didn't actually result in any changes in the rendered page. So I assume something is badly wrong with the file I uploaded but I don't know what. @Nemo, any ideas? @mdekker?

Yeah, something is definitely configured incorrectly with your mail. Probably you haven't authorized the IP that sent that mail in your SPF record and/or you aren't signing emails properly with DKIM.

I look forward to the production of one or more of the potential modules and will certainly contribute to all of them. Also happy to beta-test, of course.

@Traumflug said in Indiegogo ElasticSearch project: As far as I understand matters, thirty bees isn’t about demo’ing ElasticSearch Why do you think this would be about demoing Elasticsearch? If you have a suggestion for a better as-yet-unmentioned high speed search engine I would be very happy to hear about it. Here is a list of the basics that the search engine needs to provide: High performance full-text search High performance faceted search (this allows for high speed result filtering) Should support synonyms, typos/misspellings, autocomplete, and search suggestions Flexible indexing with index weighting Scaleable from small shops with a few thousand products to very large shops with 100000, 1mil, or more products. Free (and Open Source so it will stay free.) Relatively light on resources so smaller shops can run it on their web server. Easy to configure Should require little or no store-owner management (like Apache or Redis, once installed they mostly "just work") Should provide a standardized API that the module can use to easily execute searches -- nothing based on complex SQL queries. Under active development with a strong community already in place so the future is relatively bright To my knowledge there is only one currently available solution that meets the above requirements and that is Elasticsearch. High speed search is a complex topic and I'm the first to admit that there are many things that I don't know or understand. However high speed search has fascinated me for years and I have done quite a bit of reading & research. If there is 30bz-suitable OSS search engine out there that I don't know about I would like to learn. Right now this sheet reads much like “we barely know what we want, but we want everything”. A nice recipe for disappointment. The current spec sheet is based on features currently provided by the best ES modules. There is no single module for PS that provides all of the mentioned features but everything mentioned is possible to do with ES. There are more features not mentioned that ES can also provide. None of this is wishful thinking or created from a lack of understanding of what is possible or what ES is able to do. Discussing and refining a spec sheet not only expresses user/merchant/donator expectations, it also helps aligning these expectations with the developer’s ideas and help him laying out a plan on how to write the code. Discussion and improvement is the goal. Writing like you have a complete understanding of the topic when you actually haven't done even basic research is not helpful in moving forward.

@moy2010 said in Indiegogo ElasticSearch project: Traumflug points are just logical. If you don't ask for A in the specifications, A won't be there in the module. He's not saying if it's easy or hard. The problem is @Traumflug writes like he has an authoritative knowledge on the subject of Elasticsearch when it's clear he has little idea what he's talking about or asking for. When this is pointed out he claims that things that have been clearly explained (like ES being free, being able to run on local servers, being able to run on remote servers...) haven't been explained and that people (everyone else in this thread) should do a better job of explaining things instead of getting caught up in "buzzword euphoria". The man seems incapable of admitting error. Regarding his requests: @Traumflug said in Indiegogo ElasticSearch project: Now being clear it should become a local service, I'd like to add these to the specifications sheet: Use it as a local service (well, obviously). Not necessary, and actually a bad idea that would make the module inflexible. Also directly conflicts with the need for high performance search on multi-node clusters for a very large site, as listed in the specs already. Detect presence of this service automatically. Not possible as the service could be anywhere. Local, remote, multi-node cluster. At most, ask for entering a single address/port/name. All that is necessary to use ES is to enter the IP address(es) and port(s) of the ES node(s) the module is to use. ES has no authentication requirements and will accept queries from any IP that is granted access to it. Abstract the service connector, to make a change to the next generation search engine possible. This would add an extra level of overhead that would slow down performance. It's an Elasticsearch module, let it work with Elasticsearch. The whole idea is to be no-holds-barred fast. Make it an extension to the standard search module, so merchants don't have to configure this (choose hooks, define blacklist, define fields to be indexed/searched) twice. Alternatively, provide a common configuration page for all search engines. This is a search module, now the suggestions are to modify the way 30bz itself works? That seems very over the top to me. Make it a good and fast search module for those who want fast & effective search. Keep search engine choice transparent to the theme. Front office themes shouldn't have to care about which search engine is currently at work. This is unlikely to be possible because ES can do so much more than standard search can. Doing this would either cripple the ES module or would require modifying 30bz itself extensively. Implement features like infinite scroll, cancel button, price slider in an engine-agnostic way. That probably means outside the module. This is a good idea but again would require considerable modifications to 30bz to work. Perhaps in a later version of 30bz this could be added. If functionality requires additional hooks, or extension of existing hooks, or new Ajax callbacks, implement that for standard search, too. With dummy answers if not applicable. In order to keep the search engine choice away from the theme and other parts of the shop software. Again, requires modifying the way 30bz itself works. Extensive modifications like this would probably result in breaks in compatibility with PS 1.6. Maybe this could be considered for a later version of 30bz but I'm not sure it would be worth it. Standard search is slow and quite resource intensive already, those who want more features and better search can use....the ES module. /rant off