dynambee

@ajensen27 said in Onepage Check-out like presta 1.7: There is no difference to the customers account other than a password. But most customers don't know that. Some feel it takes longer to register. Some feel their information is being stored (even though it's being stored with guest checkout too). Some don't want to enter a password and have to remember it. Etc Etc. There's been numerous articles on the benefits of offering a guest checkout. I consider these guys below the best in the biz at dealing with ecommerce conversions. This is a good read and also states that guest checkouts should always be used. https://conversionxl.com/how-to-design-an-ecommerce-checkout-flow-that-converts/#sign-up-process-to-create-an-account-or-not A simple checkout process based on the principles presented on that CXL page would be amazing. My preference would be the "better #3" design with the option to include what "better #4" does on the post-purchase "thank you page".

I should've been clearer that I was only talking about product photos, the types of photos that are typically used on eCommerce websites.

I mean with regards to the items in the cart. You can change the quantities and delete items from the cart directly on the checkout page, at least in Japan. (You click on that "Qty" list item under the item and you can change quantity or remove.) As far as the rest goes, that's basically returning to the main site then (search, browse, etc) and avoiding that is the goal of having a simplified checkout screen in the first place.

Interesting about being able to return to the cart. I don't see a lot of need for that with Amazon's checkout as there isn't anything you can do on the cart page that you can't do on the checkout page itself.

Much of 30bz is being rewritten to fix the bugs, security holes, and performance problems that exist in PS 1.6.x. The rewrite is being done in such a way that it remains mostly compatible with PS 1.6.x but there are extensions and new features being added to 30bz that don't exist in PS 1.6.x. Being able to do this is the reason for the fork. The result of the rewrite and extensions is that while many (but far from all) PS 1.6.x modules & themes will work on 30bz there will be lots of things that 30bz can do that PS 1.6.x can't -- including the blog. You should try 30bz on a separate server and see what you think. The performance and other improvements are seriously impressive and will only get better from now.

@ajensen27 said in Onepage Check-out like presta 1.7: It would also be nice if the header would minimize too. I've started seeing this on a lot of websites (amazon, bed bath beyond, etc) where once you are in the check out process, only the logo is shown so that there are no distractions to leave the checkout process. Amazon Japan does this now too. Once you're on the checkout page(s) there is no header at all anymore, just the logo in the center. The logo isn't even clickable, it's just there as a reminder of what site you're on. There is some footer text but not a full footer, and the footer text that is there is grayed out to not be distracting.

@Havouza said in Gz compress images: Insight claim my png should be 77% smaller I missed this message earlier somehow, and what they say is very possible. PNG is a lossless image file format. It has very good compression but without using special trickery the files will always be much larger than JPG files with similar image quality. If you find those PNG files and convert them to JPG they will be much smaller.

I think my edit was too late to be seen before you replied, @Havouza. I had a look at the images on your site and they are already very compressed. Perhaps over compressed as there is quite a lot of jpeg artifacting in some of them. (I know this isn't your choice as you get the images from your supplier.) In the future (for a different site, perhaps) if you do need to re-compress images in batches you can automate this with a simple script for ImageMagick. I automate the resizing and watermarking of all my images with ImageMagick and once it's set up it's such a huge time saver.

It might be that the images on your pages could use a "lower" JPEG image quality setting without much if any impact on the resulting image quality. Google talks about this a bit here: https://developers.google.com/speed/docs/insights/OptimizeImages Edit: Looking at the site linked in your signature I don't think there are any gains to be made from additional compression. There is already jpeg artifacting in the images I looked at, and they aren't excessively large images or anything like that either. Maybe the recommendation was for a few specific images on your site?

I don't claim to be a hosting expert but NGINX themselves have an interesting and overall fairly informative writeup of the history and differences between NGINX and Apache: https://www.nginx.com/blog/nginx-vs-apache-our-view/

@mdekker said in Short Description Max 400: Interesting, I found this limit: https://github.com/thirtybees/thirtybees/blob/1.0.1/controllers/admin/AdminProductsController.php#L1913-L1917 Even if the description is configured to be more than 400, it will reset to 400. The original idea was to allow only 400 characters and it strips the HTML characters before counting, so basically the other 65,130 characters are reserved for any HTML you would like to add to the short description. Seems like overkill to me. I don't use PHP regularly and I'm pretty terrible at hacking my way around it when necessary but doesn't that section (specifically lines 1915-1917) set the limit to be 400 if the limit is defined as less than or equal to zero? if ($limit <= 0) { $limit = 400; }

@alwayspaws said in Let's talk about Search!: Is Algolia search going to be part of thirty bees? (in other words, no cost?) It sounds like the module will be available for 30bz, and 30bz have said that in-house modules will be free, something I am deeply appreciative of. There would still be monthly costs for the Algolia service itself. Paying monthly for Algolia is not unreasonable for most stores as there is a cost to running Elasticsearch as well. Elasticsearch is memory hungry so for effective production use you need at least a VPS with 8GB of memory but it will be happier in most stores if there is 16GB of memory. This is a lot more expensive than the cost of a basic VPS or shared hosting platform that can happily run 30bz without Elasticsearch. So for a single site it will generally be cheaper to use Algolia than to pay for a server that can effectively host Elasticsearch. Things change when you start looking at running 10 sites or 100 sites, or if you have a very large catalog. In these cases it will generally be cheaper to run Elasticsearch, sometimes dramatically cheaper. There are other differences as well of course, some in favor of Algolia and others in favor of locally hosted search. There's no one-size-fits-all perfect solution.

I am getting quite close to uploading ~3000 items to a development store. Just working on the final bits of the upload process via the API and then I will be doing some testing. Once I have the items uploaded I'll open the development store for people to try out search again.

@Havouza said in Short Description Max 400: 0=0 ;-) It actually seems like in this case 0=400...

In the database table (tbproductlang) both [description] and [description_short] are of TEXT type which allows up to 65,535 characters. You should be able to set the limit to anything up to ~65,530 if you wish. It goes without saying of course that actually using such a long "short" description would wreak havoc with most templates.

Yes, all seems fine now. I'll start working through the JA modules bit by bit. Is anyone else working on JA? I see a small percentage of translations have been "approved", is this inherited from PS or...?

Yes, still suspended. I can access the page you linked to but as soon as I click on any of the files listed I get the "project suspended" message.

I went to have a look at the Japanese translation but the project on crowdin is suspended currently. When I click on something to have a look it says, "The project you are trying to translate is currently suspended. We recommend you to contact the project owner for more information." It seems the project owner is @lesley, so maybe you could have a look? (I do speak/read/write Japanese but I'm not sure if I will be able to contribute enough time right now to make significant progress.)

I have a lot of experience fighting with the PS shipping setup, which is currently unchanged in 30bz 1.0.x. Did you make a copy of your site and migrate the copy as a test? If you have some sort of development or test website that is experiencing these problems I'd be happy to have a look at the carrier setup in the back office and in the database tables and see if I can tell you what has gone wrong, and how to fix it. If you're interested we can work out a way for you to send me credentials so I can check things out. No guarantees I can fix it, but also no cost even if I do fix it. :)

I don't have a functioning site yet, but I'm getting close! I like the idea of Elasticsearch mostly because of the number of sites I want to launch using the automation I'm currently putting in place. Between automation and a large available catalog, having to pay $$$ to $$$$ per month for any specific aspect of each site will be financially difficult. This makes my situation rather unusual as I'm willing to put in more work to save that $$$ to $$$$ than most other store owners would be. $$$ x 1 isn't so bad. $$$ x 10+ is too much for me right now. On the other hand, I do fully understand that you, @lesley, and other people building 30bz need to make some money off the project at some point or the project will die. I hope to find a way to contribute in both time and with finances as things improve financially for me.

I've found another production site using BRAD search but it appears to be a newer version. It's hosted in (of all places!) Iran: Site in Persian They use Cloudflare for DNS but they don't have Cloudflare's caching turned on, so I could see their IP and hosting location. Google Translate does a decent job with the site but BRAD doesn't seem to work on the post-translate site. Not too surprising really since the translation is passing through Google's servers which will likely cause problems with AJAX functions. Persian is a right-to-left language so the site is a little odd to use but the search performance is impressive, especially considering Iran isn't thought to have particularly fast Internet. Some sample search terms to try include: kardon portable digital bluetooth The site does not have fuzzy search turned on so spelling mistakes will not return results. They do have category result options enabled though: Original Persian Google Translate English Again the Google Translate version doesn't seem to work with AJAX updates but it gives you an idea what the options are. Clicking on various options on the Persian site does give results. There seems to be a bug with the color selection setup, once I chose a color I couldn't deselect it any more. Anyway, it's interesting to see what's possible, I hope to have a live sample site I can post later this month. I'll certainly share whatever I manage to learn about setup and implementation with the community.

I have found a live production site that uses an older version of BRAD search that used Elasticsearch 1.7. I tested this older version BRAD search using Elasticsearch 1.7 about a year ago and the biggest difference I noticed was that the instant search results were much slower than with the newer versions. For me, the most interesting thing to be seen on this site with the older version of BRAD search is the ability to refine subcategory results, shown in the left column of these pages: https://www.deelat.com/vehicle-fleet-maintenance/drones/ https://www.deelat.com/fasteners/flange-screws/hex-flange/ The sliders and check boxes can be configured within the BRAD module, but I have no ability to figure out how to get them to show up within a template or how to get different sets of options for different categories.

The "Follow us" social media links in the default theme still point to PS rather than TB. Not exactly a serious issue but maybe something to adjust before the next release.

The REI checkout process is nice, but what I saw (in the Guest Checkout) doesn't strike me as a "one page checkout". Maybe my concept isn't right but isn't a one page checkout where everything is visible on one page and the customer fills everything out on one page and clicks one button to complete their order? The REI process was "fill in your name & address, and click continue" after a slight pause this is followed by "choose your shipping method and click continue", which results in another slight pause followed by "confirm your billing address and membership number, and click continue..." etc. It's an AJAX system but it's not all presented on a single page with a single "complete order" button.

@alwayspaws said in How to handle products that need to be in two main categories?: When I go to upload csv, it says you can't have the same name twice. That's sort of the problem. "Note that the Category import does not support having two categories with the same name. Note that you can have several products with the same reference." I definitely have multiple subcategories with the same category name on my dev site. The category tree was built through the API rather than through a CSV but as long as you are specifying the parent category(s) properly then at least as far as TB is concerned it is no problem. In other words, this would be okay: Made in USA --> T-Shirts Not Made in USA --> T-Shirts Is there a limitation with the CSV importer that doesn't make this possible? Or maybe I'm just not understanding the issue properly.