dynambee

The question I would ask them first is at what point do they force guests to register? PayPal has guest checkout as well but after a certain number of transactions and/or a certain dollar amount they seem to force customers to register. PayPal's market penetration is so big that this isn't a massive problem but with a smaller processor it could be a barrier to sales. (This information probably won't be on their website but perhaps their level 2 or higher tech support could give you an answer.)

@Havouza said in Split Payments: I will change my answer after getting an answer from the tech support at Payza. It is fully possible to do what I want using Payza, so now I only need a programmer to make the module ;-) Do customers need a Payza account to make payments, like with (basic) PayPal? Or is it more like Stripe where customers just pay with credit cards...?

Talk to the dropshipper and see how they expect to be paid. If they're a legitimate dropshipping business then they will have various options available. Do NOT wire money, do NOT use BTC, do NOT send via Western Union, etc. Perhaps once you have a long standing relationship and have visited the company in person you might consider these options but you must understand they provide you with no protection at all, you assume all the risk.

@Havouza said in Split Payments: @mdekker Paypal pay out directly when you order the transfer. I get my money max 2 days after the request PayPal will place restrictions on accounts that have little history or that have a history with too many disputes/chargebacks. These can include holding all funds for a period of time (7 days, for example), keeping a rolling reserve of all incoming payments (25% for 30 days, for example). These types of restrictions are common across the payment processing industry as a form of risk exposure reduction. Another thing that can trigger restrictions is a sudden increase in sales. If a seller has been putting through $10k per month for the last few years and suddenly that jumps to $150k a month there will probably be restrictions added to the account until PayPal are confident that the new volume is legitimate and that the company can manage this sort of volume effectively. If an account holder expects a dramatic change in sales numbers then contacting PayPal in advance to discuss this with them is also a good idea. Restrictions are less likely if they are kept in the loop and are confident that the account owner is planning for the increased sales volume. All of this is completely normal in the payment processing industry. Consumer protection laws mean that processing payments carries quite a lot of risk for the processor so they do as much as they can to manage that risk effectively.

@mdekker said in Split Payments: Doesn't take a PayPal clearing up to 7 days as well? As with just about everything related to payment processing... "it depends". PayPal has received a lot of hate over the years for putting rolling reserves on accounts or holding funds for a certain period before releasing them. Really though these types of things are just standard practice in the payment processing industry. Once a business has a strong history with a given payment processor then there are generally fewer restrictions placed or restrictions that have been placed can be eased. Sometimes this requires asking (nicely of course) for changes to be made to the account. My US company has a Stripe account set up that we haven't used yet. I'm definitely curious what will happen when we start to run some business through it. We have a very strong history with PayPal, they don't even hold funds in the account anymore if a customer opens a dispute. Regarding splitting payments, the best thing to do is to reach out to PayPal and ask. It's always good to have an open line of communication with your payment processor anyway, that way if there are any problems they know they can contact you.

I've edited my post above about the 8GB as it seems to have been adding to the confusion. Perhaps @mdekker could edit his as well. With more testing it's clear that 8GB is not necessary for a single web store of reasonable size. Except for large stores with heavy traffic it seems very possible to run ES on the same server as MySQL and the webserver are running. ES, btw, is not CPU intensive for normal use. It just needs memory. As long as the server has enough memory to hold the dataset without causing problems for other services on the same server then there really should be no problem with a single server ThirtyBees install. I don't have any live sites I can test this on right now but I will certainly add information as I learn more.

As always there is a relevant XKCD. For anyone who hasn't been to XKCD before, be sure to hover over the comic image to get the ALT text. In CS and related disciplines things that seem like they should be easy are often not easy, and it can be very hard to explain exactly why that is.

@Traumflug said in The Caching Mystery: This discussion pretty clearly shows why setting up a shop is considered to be hard. People expect it to be hard, a self fulfilling prophecy. Accordingly these people have zero vision on how to make it a couple-of-clicks experience. It clearly can be done. If you really believe it is so easy to do what Shopify has done I suggest you set up a business that competes with Shopify. Shopify had gross revenues of $390 million in 2016 but a net loss of $37 million. However since it's so easy to build a system as simple to use as Shopify you should be able to do it with very few staff and reap massive profits. You could undercut them slightly on price and your growth would be stratospheric. Imagine how much you could spend on marketing with such a low tech overhead. Perhaps I shouldn't be so sarcastic, you clearly know much more about this than me. Me and the combined developers of every open source shopping cart on the planet. How could they not see how easy it would be to make their systems super easy to use? Someone should tell them! I look forward to your future shopping cart SaaS business success. Don't forget about us plebes while you're relaxing on your future private island. /sarcasm-off Edit: Added top quote for context, added minor clarification to last paragraph.

@Traumflug said in The Caching Mystery: You knew which hardware you were willing to support and you had control over the codebase that would be run on that hardware. That's exactly what 30bz has, too. 30bz doesn't even know what OS the system will run on -- Linux? BSD? Windows? OSX? They don't know what services will be available. They don't even know what web server will be used. Beyond that they have no idea what versions will be on a given host, and hardware varies wildly from shared hosts like Dreamhost to multiple dedicated servers. People also modify the codebase all the time and stores use multiple modules that may or may not have been developed following any sort of reasonable guidelines. It's massively more complex than any embedded system. Embedded development presents its own challenges but from a complexity of possible configurations standpoint I'm not sure how you can even compare the two, to be honest. Shopify but it’s because they have done an incredible job. Shopify did what a thirty bees user should be able to do within an hour. If it was possible for a non-technical user to emulate what Shopify provides with an hour of work then Shopify wouldn't exist. I don't mean this in any sort of insulting way but I think you are greatly simplifying the complexity of what is running on the typical web hosting platform, and how much work goes into making all of that simple to use. 10% of the work is in putting a functional base platform together, 90% of the work is in making it easy to use and difficult to screw up. I simply don't buy this "it's all too complicated". PHP has a well defined API, Apache has the same, as has MySQL. Many users demonstrate here that setting up a shop can be done in short time. So let's make this even easier! Who says a server will be running Apache or MySQL? nginx and MariaDB are just as likely and could be better choices. LiteSpeed is an option on some hosts too, and of course IIS. Who knows which version any of this will be? Some hosts update all the time, some hosts patch old versions instead of updating. Even PHP could be one of a bunch of versions and can be installed in multiple different ways. There is no "standard" web configuration. As far as ease of use is concerned I think 30bz already makes all the underlying complexity easy to use. Yes, some sort of add-on to help with cache configuration would be nice but there is no getting around that the user still needs to have some understanding of how all this works. At some point something will go wrong. Corrupt cache, a cache that needs to be manually refreshed, a compatibility issue... These types of things happen to all stores and require a degree of active management. Unless the store owner pays someone else to take care of their store then they are going to have to learn how to do these types of things.

@Traumflug said in The Caching Mystery: Some hosts don’t offer some cache types, as @MockoB mentioned. Some hosts offer a cache type but only in an older version. Such stuff can be detected automatically. No need to put that burden onto the user. Sometimes yes, sometimes no. The advantage of an SaaS is that the software developers know exactly what the system will be running on, and exactly how the system will be configured. They know what services will be available, the addresses the services are on, and what port numbers will be used. They might not control the baremetal hardware but they will control everything from the OS layer through to the SaaS software the user is paying for. This makes everything immeasurably easier to manage. There are no "special cases" or oddball configurations. How would 30bz detect that there is an ES server available on a different IP? How would they know if redis was configured and available but on a non-standard port? There are too many options. Sometimes a module will conflict with a certain type of caching as well This is a problem the module developer should deal with. Again, no need to bother the user with it. Sure, in theory. In reality a shop owner just bought a module and now they have to figure out why it isn't working properly. Some developers will be helpful, some will not. Especially since 30bz is a fork some developers won't be super interested in helping out. you guys could do this because you had complete control over the system. Actually we didn't. You did though. You knew which hardware you were willing to support and you had control over the codebase that would be run on that hardware. It's not SaaS level control but it's much more control than any open source shopping cart has. OK, I'll stop now. Web software was always complicated in the details, so it'll take time until users get used to simplicity. It's complicated because of the nature of the Internet and the nature of open source software. This is unlikely to change any time soon due to the desire for variety and flexibility. For those that have a need for a highly standardized shopping cart with little config required and no tech knowledge then Shopify exists. I know I keep mentioning Shopify but it's because they have done an incredible job. They have an excellent platform with strong performance and a good API. It's expensive but for what they provide it's a good value for many people, especially if you do not have to pay their transaction fees. IMO there is no other shopping cart SaaS system that comes close to what they offer. It's not surprising that they have grown as quickly as they have.

I think you first question should be if such a custom theme will even work properly with 30bz. The more custom work done in a theme the higher the chance of having compatibility issues. Maybe talk to the designer and see if they are willing to test the theme on 30bz, if they will help you get it working on 30bz, and/or if they will offer a money-back guarantee if you can't get the theme to work on 30bz. Once the compatibility is worked out the overall performance with 30bz should be higher than with PS, but exactly how much higher will depend on why the sites you mention are so slow.

This flexibility isn’t of much point if there’s no help to decide which settings fit best. Accordingly one needs some performance measurement system. I’m not aware of one other than turning on profiling, playing around and looking at the numbers. Website performance is generally measured using 3rd party tools that check page speed, number of requests to load a page, the types of caching used, images types & compression, how cookies are set up, etc. Turning different types of caching on and off will generally impact the results from these tools in repeatable ways. If some caching system always improves performance, there’s not much point in allowing to turn it off individually. Some hosts don't offer some cache types, as @MockoB mentioned. Some hosts offer a cache type but only in an older version. Sometimes there are also multiple options for the same type of caching so a site will have to choose the one that a) their host offers b) is compatible with the modules they are using and c) that gives the best overall performance. Sometimes using a given type of cache would be ideal but the server being used doesn't have enough memory to use it. Sometimes a module will conflict with a certain type of caching as well, in which case the shop owner will have to decide between using the module or using the cache. That’s why I think there should be a single on/off button. Developers can test each cache strategy and do the individual decision for or against a system at development time already. SaaS providers can do it, too, after all. This is possible on a SaaS platform because the business running that platform has complete control over the platform. You can't write a Shopify module that screws with the fundamentals of the Shopify platform because Shopify doesn't give module developers that level of access. With an open source solution any module developer, theme developer, or even shop owner can do anything they want to any of the code. They shouldn't, of course, but they can. This leads to many of the problems and incompatibilities. These incompatibilities often don't show up in every configuration but only in certain configurations. Sometimes one version of the cart will be fine but a later version will have problems. This mostly comes from module developers (and sometimes theme developers) not following the published guidelines for what they are building. Sometimes they know they can get better performance if they do things a certain way, sometimes it's just bad coding, and sometimes there may be no other way to do what they want to do. The upside of being an open source cart is complete access and total flexibility. The downside of being an open source cart is also complete access and total flexibility... To give an example from embedded development (3D printer controller) Again, you guys could do this because you had complete control over the system. If you had 10,000 random developers also making changes, additions, deletions, etc in ways they thought best you would never have been able to do what you did.

I'm not a cache expert, I know just enough to be dangerous. (A great expression my mother used to use.) For example, what is the point of a database cache? A DB server should know best how to use available RAM for maximum performance. A database cache like redis turns a general-purpose database like MySQL or MariaDB into a high performance monster capable of feats that far exceed what the database itself is capable of. This is important in scenarios where a system has far more "reads" than "updates" -- a web server, for example. There are also databases designed for mostly for performance but they have other trade offs which make them less desirable. Using MySQL/MariaDB + redis is a "best of both worlds" scenario. The well understood MySQL structure, better data integrity & consistency, but still the performance of far faster systems. It's great the 30bz is offering redis. Trying to use a single "on/off" button to manage all cache settings seems like an ideal option but it removes all flexibility. Some modules don't play well with some types of caching. Some combinations of modules will have the same issue. Being able to turn on & off different types of cache is important when you are troubleshooting problems on your website. Rather than a single toggle perhaps some information on a recommended standard configuration for shops that don't have a lot of modules installed would be nice. Maybe, when the devs have time, a 30bz module that can be installed with a toggle switch for the default caching configuration. In the end the topic of caching comes down to the same thing I said in the "Let's talk about Search" thread: The advantage of SaaS systems like Shopify is that they do manage all of this stuff for users. User-managed webshops like 30bz require the user to learn more and then apply that knowledge. That gives us all tremendous power but it does require an investment of time & effort. The benefit to this is a more flexible site, the ability to scale to multiple sites if desired, and the lack of a big SaaS bill every month.

@moy2010 said in Let's talk about Search!: 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 :). I'd be very interested in hearing more about your current ES setup, how many products you have in your store, and what sort of custom ES setup you are working towards now.

@mdekker said in Let's talk about Search!: What's so great about it? Now I want to know! Is it just because of the weights you can add? The custom search and index settings? It pretty much covers all the bases: can manually choose which fields get indexed and which do not. set weight for each field type separately select the search operator (AND, OR, etc) can automatically disable elasticsearch during indexing processes. If the server is already overloaded then ES queries may be very slow during an index. If this setting is turned on then the site falls back to standard PS search during indexes to avoid problems. can force exact word match only (i wouldn't want this but i can see how some sites might) can set min and max word lengths easy to edit the word blocklist supports clustering for very large sites that have enough traffic that they might need it has logging support can choose when to index -- autoindex at time of adding an item, batch based scheduled index, or manual index As an added bonus it's been under active development for 2 years so I would guess most of the bigger issues have been worked out.

@Havouza said in Let's talk about Search!: @dynambee https://addons.prestashop.com/en/search-filters/19527-elasticsearchconnector.html Wow, that's a very well put together Elasticsearch Module. It does pretty much everything I would put on a search module wishlist. The only thing I don't see mentioned much is filtering results but their own website has filters on it so I imagine their module supports it too. I'd be curious to test it and see how good the search results are, and I might just fork over the 130 Euro to do that. Very tempting, and a great find! Thanks for sharing it.

@Havouza said in Let's talk about Search!: All this is good but again we talk tech guys, not my cousin that is born totally tech zero but is a premium merchant. He has no clue about i-click install or vps or.... But he is super also on economy and realize the trap with platforms like Shopify. There is always going to be a trade-off. The costly solutions (Shopify, Algolia, etc) do everything even if the shop owner doesn't know much about tech. All those fees go to pay a large staff of tech people and all the hardware & software they use to make the magic happen. The same for hosted Elasticsearch and all other SaaS solutions. On the other hand there are a selection of free software solutions that require some time & knowledge to use. That includes 30bz of course, it requires much more knowledge to effectively use 30bz than it does to effectively use Shopify, for example. Elasticsearch is no different in this regard. The level of power provided by Elasticsearch is staggering, and it is available for free. That's incredible if you think about it for a bit. Yes, some time & effort may be required to set it up, or in the case of Cloudways, the ability to click a checkbox and then choose "save" (that's seriously all that is required). If clicking a checkbox and choosing save is too much to ask of someone then they are going to have a hard time installing & configuring the PayPal module, the Shopify module, and just about everything else, too. For these people services like Shopify exist. That's not meant in any sort of negative way, some people will just find it very worthwhile to use a hosted SaaS where the back end things are taken care of for them. We all do this for some things. I don't do my own car repairs, I take it to a shop. However I can do my own Elasticsearch setup, so I do that. About hosted elastic search. I have only looked at their own cloud pricing and a setup with 2 Gb ram and 48 Gb storage cost 79 $ per month. Same time they state that less than 8 Gb is very bad As I learn more about Elasticsearch it is becoming clear that vast amounts of memory are not needed for the type of index required by most web shops. That memory is used to store indexes for ultra high speed searching. If the indexes can't be stored in memory then fast search won't work. For the volume of data that ES usually manages a large server (or cluster of servers) is required. However for a web shop with a few thousand products it seems very possible to use something like what Cloudways provides. It even worked fine on my tiny 2GB server even though ES was sharing memory with MySQL, Apache, redis, nginx, and some other services. I thought the search problems I experienced may have been because of not enough memory but it turns out they were because of limitations of the BRAD module and because of limitations in my own understanding of ES. Btw most discussion has been around Elastic/Brad. I see there is an expensive polish PD module. Anyone has tested? I tried to figure out what you mean here but unfortunately I'm not sure. Can you link to it or give more details?

@Havouza said in Let's talk about Search!: This thread has been very interesting to follow. But again most of the discussion is for the nerds that is members of this forum, not for all of the ones that is merchants only, not tech freaks. Search is really something a person can geek out on. It's always interested me because good search makes a system/store/website a joy to use while slow or non-functional search leads to immense frustration, at least for me. What shoud they choose, They ofc want a very good system. Not all of them will go to Shopify or Bigcommerce or whatever, its very expensive. I'm definitely not going with a packaged system. They can be a good fit for some people but it's not for me. So for them it reall does not matter, Algolia is there quite easy to setup but can cost a lot. But that is really the same for Elastic. If you want to use the Cloudservice they provide, it quite quickly get very high priced. Algolia has a free option that should be fine for stores with 1000 to 2000 items as long a they aren't too busy with visitors. I don't know if they limit features or performance but they do force a logo to be displayed on your site which is not ideal. Elasticsearch also doesn't have to be expensive. For a similarly sized store it shouldn't be a problem to run Elasticsearch on a smallish VPS together with the web and db servers. If you site gets busier or your catalog grows then something else will need to be done but a separate small VPS should be enough for even a relatively large (~100,000 products) store. I don't know about other hosts but I know that Cloudways offers Elasticsearch on their plans. Just check a box to turn it on, no configuration necessary. Why is it so? Computer power and bandwidth is cheap nowadays. I would like to see a very good TB module that can connect to a good priced Elastic provider. Not one that charge hundreds and hundreds per month. It is fully possible, someone just have to start Most of the hosted ES cloud providers are focused on larger installations and are priced to match. They also tend to be on AWS which is expensive compared to many cloud hosts. I think that with 30bz being open source it would be nice if the standard "advanced fast search" module used an open source search engine, but unfortunately I don't have the skill to code the search module myself. :(

@roband7 said in Let's talk about Search!: @dynambee I agree with all your points. I'm surprised the focus is so much on performance, when the low volumes we're talking about here is just a joke both for ES and Algolia. The performance of "as you type instant search results" is in large part about latency. PS & 30bz both provide "instant" search but the latency is terrible so it's not really functional. Nothing against 30bz of course, MySQL full text indexing just isn't fast enough for instant search. This performance bottleneck can be solved with either ES or Algolia. However for websites the distance from the site to the user is another issue and is why distributed search is such a cool thing. One very fair point in the Algolia blog post that was linked to above is that latency higher than ~100ms starts to feel laggy for instant search. If your customers are all within one geographic area then 100ms isn't a big problem. For global search it is though, a customer in Australia searching on a site in Europe probably won't have a great "instant search" experience. A couple of years ago I setup a ES-based search system that needed to search a database of 150 million complex records. The performance was excellent and the memory- and CPU-consumption was nothing to talk of. We ran it all on two cheap 16GB servers. Just to put things in perspective... This is very nice to hear. There's lots of talk online about large scale ES clusters but not a lot of information about smaller scale performance & hardware requirements. The focus here should really be on functionality, ease of installation and ease of use, not on all the technical issues. Installation & configuration will always be easier with a SaaS system. Shopify is easier to set up and use than 30bz. Algolia is easier than ES. However Shopify and Algolia are expensive, especially if you want their plans that provide better service options. Want to use 3rd party calculated shipping on Shopify? You're forced to use their $300/month plan, per website of course. Live outside the few countries that support Shopify Payments? You get to pay transaction fees for sales on your own website! Want to add any features that Shopify itself doesn't provide? Almost all are monthly subscriptions rather than one-time purchases. The costs add up in a hurry. Algolia is the same. If you have a large shop or you want lag-free search for global customers then you get to pay $300 a month. Convenience, at a price. For some people perhaps the costs aren't a big deal but unfortunately I don't fall into that group of people. :( From a functionality standpoint I think the two are similar except for Algolia's easy (but expensive) distributed search. Both provide fast search results with the ability to filter those results. A lot of the functionality depends on the quality of the search module doing the querying. It would be possible to have a fantastic ES module and a poor Algolia one, and the other way around of course too. For installation there are hosts that offer one-click ElasticSearch, like Cloudways. As long as your server has the capacity you can enable ES by clicking a checkbox and saving the choice. For hosts that don't offer this or for people who want to have a separate ES server there are already options available for relatively easy installation. I don't think it's harder to set up basic ES than any other typical web-facing service.

@mdekker said in Let's talk about Search!: I think that's a bit biased, but I could be wrong ^^ Yes, that comparison does come across as a little bit biased. ;) I think Algolia's biggest benefit starts with their $299/month plan and that is distributed search. This is great for "as you type" instant search results as the results come directly from the Algolia datacenter closest to the customer. This will be faster than if a customer is searching on a website+ES setup that is on the other side of the world. Importantly though distributed search is not offered with Algolia's $59/month plan so you do pay a big premium to get that functionality. It's also possible to have distributed search with ElasticSearch, and in fact it's one of the reasons ElasticSearch was created in the first place. I don't think it's necessary to take this complexity into consideration with any possible 30bz ES module though. If a site is big enough that they are thinking about global distributed search then they can afford to either pay Algolia or to build their own ES search module. So IMO for shops that have fewer than 30,000 products, ES is a better overall option. Algolia would be attractive to those who don't want to do anything themselves, but I suspect most users like that would just end up on Shopify anyway. (Funnily enough, Shopify also uses ElasticSearch!) For shops that exceed 35,000 records and need the $299/month plan Algolia will feel faster to customers in far away places because of the distributed search feature. Customers who are nearby probably won't notice any difference, as long as ES is set up on appropriate hardware. ES will certainly be cheaper, and it's very easy to set up an ES server. I think a lot of the points in the Algolia blog are FUD-like. Issues like sharding do need to be given some consideration when setting up an ES system but for the typical 30bz webshop owner it's not going to be a problem. You can't have more ES servers in a cluster than you have shards so if you start with 5 shards (the standard) you can't have more than 5 servers without reindexing everything. This is something that is talked about a lot in the ES community because many ES clusters are absorbing gigabytes or 10s of gigabytes of new data every day and they need to be able to grow. The typical webshop is not going to ever need more than a single ES server. This is a problem for sites like eBay (which uses ElasticSearch) but not for most smaller storefronts. @moy2010 said in Let's talk about Search!: "If you pay, Algolia does everything for you" :P Yes, that about sums it up. As an aside, I noticed that Algolia claims customers save 25% if they prepay for a year at a time. However the prices they quote are not 25% reductions. Savings on the two smaller plans are ~17% and on their largest standard plan only 10%. I realize no one is perfect but that seems kind of misleading. :(

However if you let me know what sort of testing you need done I may be able to do it. Currently I use PrestaSharp to communicate with the API so the XML is very consistent.

Not specifically, no, but I can certainly do testing in that I can test sections of the API with code known to work with the current API and then monitor what happens at the database level.

Okay. Well, API testing is certainly something I can help with when the time comes.

How big are the changes going to be with the 1.1.x branch? I'm quite tied to the API in the 1.0.x branch (from PS 1.6.1.x) and major changes in the API structure would be difficult to adapt to quickly.

Feel free to visit https://inxonline.com, my dev site, and test it out. The search box with the standard blue button is the original 30bz search. The search box under that with the black button uses Elasticsearch hosted on a separate server in the same datacenter. If accessing the site results in the "site closed" page just reply to this thread and I'll open it up again. A few points about the setup that might be of interest (or not...) These are both VULTR VPS boxes. The web/db server is 2GB and 2 cores, hosted on VULTR through Cloudways. The Elasticsearch box is 8GB and 4 cores, hosted directly on VULTR. Both servers are in VULTR's Tokyo datacenter because it's the closest one to me here in Osaka. Elasticsearch is v5.4, I downloaded a bitnami installer to get it up and running with no fuss. I had to increase max file descriptors and vm.max_map_count from the defaults that came with CENTOS 7, but this was detailed in the ES log file when it failed to start. Cloudways doesn't give users private IP addresses so I'm running this over the public IP addresses. I'll check with Cloudways to see if I can get a private IP on that box as it would be safer. For now I have firewall rules to only allow ES access from the web server IP and my office's fixed IP. If anyone here is thinking about getting a VULTR VPS they have a great promo running right now, they match your advance payment deposit dollar-for-dollar up to $100 deposited. I sent them $100 to cover hosting, they credited my new account for $200. Not bad! You can see the details here: https://www.vultr.com/coupons/ 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.