dynambee

Just a little bump in the hopes that someone has experience with this and is willing to share which way they went and perhaps why. I guess if no one has experiences either way I'll probably go with the Panda module as it seems likely to be fully integrated with the theme.

Maybe this module would work for you? The referrer program is new to the module and I haven't yet had time to test it myself. Might be the right solution though. Edit: It looks like the module does not support affiliate programs at the current time. It would definitely be a nice future addition but I'm not sure if the author will continue to add features to this module.

I guess the ability to put PayPal checkout buttons on every product page means it's not possible to change the PayPal module to use a hook that only exists on the checkout page(s)?

There are two reasons why the numeric system is important: It's not ideal for a new shop to start from customer #1 and order #1. It does not inspire trust, even if the business behind the shop has been in existence for many years. It is easy for competitors to learn a lot about a shop if customer, cart, guest, order, invoice numbers are sequential. For example, I can see how many customers you have. How many orders you have received. How many orders over a period of time. How many new customers you have collected over a period of time. How many abandoned carts you have over a period of time. From this information I can extrapolate a lot about your business, including your likely monthly and yearly sales. As I said much earlier on, some people really don't care about this but personally I do.

I've opened an issue on github about this here. I don't think it will be a difficult issue to fix. However even after this is fixed it will always be possible to create an account with a fake email address unless you force email validation before allowing a new account to make purchases. Even with validation people can use free temporary email addresses to sign up for websites. Beyond that many people use a free email account for all their online purchases and then rarely if ever actually check that account. There isn't really anything realistic that we as merchants can do to make sure we have a long term ability to communicate with customers.

I'm really sorry to hear this. I know how frustrating it can be to donate time and not get any feedback or assistance. As I mentioned above, I was kept out of the office and mostly offline by a temporary job I had for a while. This meant I wasn't able to be active on the forums or work on developing my own site, and by extension meant I wasn't testing modules either. I expect that as the TB community grows there will be more people around who can step in to do testing and provide feedback in cases such as this. Right now there are only a few of us so if one or two aren't around for a while it makes quite a difference. In any case, now that I am back I have downloaded the module and will definitely install and test it. I'm using Chex as well so maybe I'll have some feedback on how the two interact with each other.

My apologies for being MIA for the last while, I had some consulting work to do that kept me out of the office for a good number of days. I'll be back working on TB in the next little while and will definitely test the updated module. Thanks very much for your hard work!

Thank you! I will try that tonight. BTW, I noticed that with Firefox clicking on the javascript link actually causes the page to scroll down to the order details. However with Chrome the page does not scroll down, and it doesn't scroll down with Safari on iOS 13, either. Perhaps this is a bug?

I've been doing a lot of testing with my upcoming website over the past little while. I have half a dozen different test accounts set up along with matching PayPal sandbox accounts so I can test purchases & shipping calculations for various destinations. The result is that I have now managed to generate quite a bit of order history on some of these accounts. Like this: This has pushed the "order details" section far enough down the page that when I click on the "Order reference" link or on the "Details" button nothing visually happens on the page. If I scroll down far enough the order information is there, but clicking on the one of the links visually seems to do....nothing (even though in fact the order details are being loaded.) In fact I hadn't checked the Order Details recently and I actually thought one of my changes had broken something because clicking on those links didn't seem to do anything. Looking at what those links do, they are javascript triggers for AJAX page changes, which makes sense since that is what is happening. What I would like to do is change them so they are just basic URLs that load the order details onto the current page. So instead of having the order history and order details all in one place I would like something more traditional with just basic links and no AJAX calls. I've had a poke around but can't figure out where to make this change. I'd like to change this: javascript:showOrder(1, 1773945082, 'https://www.mydomain.com/order-detail?id_order=1773945082'); and this: javascript:showOrder(1, 1773945082, 'https://www.mydomain.com/order-detail'); to just be this: https://www.mydomain.com/order-detail?id_order=1773945082 in both places. Anyone know where to make the change?

As this is a feature for customer groups it seems likely it is only going to have an impact on modules that are available to front office users. However it's a feature related to modules so all modules are going to be listed there, even if the setting does nothing for them. For example, maybe you have a product review module that allows customers to review your products. You might only want to make that module's features available to users who are logged in and not to Guests. Does this functionality work? I have no idea at all. I'm just trying to guess the intention of the feature.

Also of note, if you don't want to support this (because it could create problems for people who don't understand what is going on), how about a "hidden" option in the `tb_configuration` table to enable it?

I would really, really appreciate the option to select shipping based on country alone and not needing the state. I already kind of do this by using CSS to hide the state selection dropdown from the "Choose shipping and payment method" area and have no problems with accurate shipping information as all of my carriers are defined only by country and never by state. My "Choose shipping and payment method" section looks like this: The problem is that after I go to the next section I get this: Considering the customer didn't select a state (and it's often the wrong state displayed...) it looks very strange. It would also be odd for me to ask the customer their state at this point as every state will have the same shipping options for my situation. I guess doing this would ideally affect the shipping address section as well since it separates addresses by state too: Ideally this would become: Since the above is already how Chex works for countries that do not have states defined in the TB database it doesn't seem like it would be a super difficult change to implement. If the merchant chooses to calculate shipping based only on country then the Chex system could just display the "Shipping to" destination and shipping addresses for all countries in the same way: In the Chex back office just a simple toggle would be required to change between "Country only" and "Country & State". Then in the front office this could be used to determine how options are displayed to the user. The actual shipping cost calculation system would remain the same.

The simple answer is "don't put all your categories there". What if you have more categories in the future? Just keep making it wider or the font smaller? There is a limit, and spreading all categories across the page isn't a good UX for the customer. I'm not completely sure if the default Niara theme supports putting a drop-down menu on that main bar or not, but if it does then that is an option. If it doesn't then just putting one entry called "Products" or "Catalog" (or something else that you prefer...) and a link to the main top category from which customers can browse items. My main menu bar looks like this: It's still a work in progress and I may change & simplify it more. It does quickly get customers to different parts of the site though.

How about the link to the full description? It's definitely a nice touch. (As shown on the shop @Pedalman linked to.)

Should be possible to test this pretty easily by just setting it up and then seeing if it has any impact on different customer groups.

Well you got that much right. You can use any label you want, even "angsty" if that's what floats your boat. It's an ENUM type and the options are listed in the `condition` column of the `product` table. Nothing is forced, you can show or hide that field and any other field. There are also two product code fields, `reference` and `supplier_reference`. You can use `reference` for customer viewing and `supplier_reference` for your own viewing. Best of both worlds. TB includes a very functional API. You can use it to upload any collection of carrier definitions that you wish. Personally I have nearly 300 different carriers defined on my site, multiple carriers defined for every country. Functional APIs are quite rare in open source shopping carts and the one included with TB is what first attracted me to PS 1.6 and then later TB. What you really want to do is limit carrier availability based on the total value of the items in the shopping cart, not based on the price of any individual items. If someone buys $1000 worth of cheap widgets or a single piece of jewelry for $1000 you are going to want to send that order with good shipping, tracking, and insurance. TB does not include functionality that does this, and I have not seen any other shopping cart (open source or very expensive) that does this properly. Shipping solutions are really, really hard. What happens if someone buys 5 different items that need different shipping solutions? How do you present those options during checkout without making the checkout process a nightmare for the customer? Make the customer choose shipping for each item individually? Do it automatically for the customer? What if there are two items that absolutely cannot be shipped together due to size or weight restrictions? Maybe one item needs to go in a long tube by courier and another item needs to go on a pallet by truck. To give you an idea of how hard this really is, most sites just give up and offer "free" shipping by including the cost of shipping in the item price. This is a giant pain in the ass for international shipping as the cost to ship to the country next door can be very different to ship half way around the world. And while customers love the idea of "free" shipping what most do not realize is that there is no such thing as free shipping. The shipping costs just get included in the price of the item which means if they buy multiple items they are usually overpaying for shipping costs. eBay's shipping system is a nightmare. eBay's platform is a nightmare. People will be more willing to help you if you have better manners. You never know who might have a full solution to your shipping problem but not be willing to share it because of your rant. Couriers like DHL that charge for rural delivery and charge for shipping based on volumetric weights are a nightmare for a general cart solution. Presto-Changeo has some good modules that help with this, but they aren't free. Do you seriously think you're the first person to think about this? Every single merchant running their own shop thinks about this. Every time they ship something they think about this. Shipping, especially international shipping, is a massive pain in the ass from an accurate cost calculation perspective. To get accurate shipping costs you first need to calculate which box the items in the shopping cart will fit into. That means you need an accurate size and weight for every item, and you need an effective 3D Bin Packing system. 3DBP is an NP hard problem and even companies that have thrown substantial amounts of money at this (Amazon...) don't have a good solution. Those are changes you want for your particular needs. Other merchants have different needs. If you want a custom shipping solution that exactly fits your needs then you will probably have to pay to have a shipping module written specifically for you. You might find one that is "close enough" from somewhere like Presto-Changeo (link above) but you might not. Custom work is expensive so most people end up going with a "good enough" solution that mostly fits what they want to do. If you look more deeply into the system TB offers already you will find that it is actually more flexible than you think. It's not perfect but it's not bad. Of course you can do this. You can define shipping zones however you want to define them. If that means you want one country per zone or even one state per zone, you can do this. Well your very first word and very last word are accurate. So you've got that going for you, which is nice. You need to learn that there is no perfect shopping cart out there. It doesn't matter if it is an open source cart like TB or one you pay monthly for like Shopify, there will be limitations and decisions they have made that don't fit your needs. The thing with an open source cart like TB is that if you are willing to learn the skills (or pay the money for custom development) you can make it do anything you want.

If you use one or the other I'd love to hear your experiences too! What do you like? What do you wish could be better? Any major problems that you have come across?

My website launch is finally getting closer and I'm starting to look at blog content to put on the site. Inevitably that means considering which blog module to use, too. I've ended up going with Jonny's Panda theme because of how easily customizable it is, especially how I can easily optimize it for mobile with things like different logos for mobile use. This is in no way meant to be an attack on the included Niara theme. I like Niara, a lot, but I don't have time to learn how to hand craft it for mobile use right now. This brings me to the blog module. Thirty Bees has a blog module. Panda comes with a blog module. I know very little about these two different modules or which would be better to use. I assume that if I start with one of them that migrating to the other will be a giant pain in the ass so I'd like to get it right from the start. So... Which one should I use? Does it even matter that much? Are there any big pluses and minuses to either option? If anyone out there has tried both I would really love to hear your experiences.

I highly recommend trying out @datakick's Chex one page checkout module. There's a thread with many pages of discussion and improvements here. There's a free trial so you can test it without having to buy it first but IMO it is very much worth the price. It's the best checkout experience for TB or PS and I don't think I have seen a better checkout for any other platform, either.

I have spent the last few hours working with this and doing a lot of testing. I discovered that the Cart ID is also exposed easily during the payment process when people are sent back from PayPal after completing payment. It's also visible when using the site if you use Chrome's console. Adding 'Cart' to the list of classes in the above code fixed that problem and the Cart IDs are now random. Another issue I came across is that while the order reference column is defined in the TB database as VARCHAR(100) the length of reference numbers is still limited to 9 characters by the TB code. I reported this as a bug on github. Next issue is that ideally I would like the id_order, order reference #, invoice #, and delivery slip # to all match as it makes things easier for customers if everything is the same. I found this nice little module (called "modrefchange") that seems like it might do exactly that but there seems to be one problem. I set the modrefchange module use the Order ID for the order reference #, invoice #, and delivery slip #. It successfully uses the order ID for both the invoice # and the delivery slip # but the order reference # is being overridden with a different random number. So I guess my next (and hopefully last!) question about this is... Is there a way I can generate random `id_order` fields but not generate random `reference` fields? That way the module can use the `id_order` value for the reference, invoice, and delivery numbers.

Usually when I kill something so early on I just nuke it all and reinstall. I've also learned to make backups regularly. I actually have a small bit of VB.NET code that I wrote that does backups remotely over SSH/SFTP. It puts the shop into maintenance mode (if it's not there already) and then zips the entire directory tree. Then it dumps the database into an SQL file and zips that too. Then it transfers the whole lot back to my local machine and puts it into a folder named with the site name & a timestamp. Once everything is done it enables the shop again if it had to disable it at the start. Then when I inevitably screw something up I have a way to recover quickly. This has saved me so much time and frustration.

You're very likely right as you know a lot more about TB's internals than I do. I just have a long list of things I go through and try before asking for help in the hopes of fixing anything easy.

It's also important to make sure the file ownership is correctly set. Often the webserver is running on a different process to who you log into SSH/SFTP as and that results in the file ownerships being set differently to the webserver process.

Maybe someone will come along who has an immediate solution for your current issues but in the meantime I can make some general suggestions that might help, depending on what you have already tried: In the back office under `Advanced Parameters -> Performance` make sure that template recompilation is set to "Force compilation" and that all types of caching are disabled. If your webserver is running any sort of caching you may want to disable that during development and testing as well. It's great to use on a live site but as with all other caching it can cause weird problems during development. Disable any & all CDN caching you may have set up. It can cause weird & unexpected problems during development. Reset all file permissions in your public_html directory & subdirectories to 755 for folders and 644 for files. Make sure the file & folder ownership is set correctly as well. Some web hosts have a button you can press to do this automatically. Some you must do this yourself from the command line. Make sure that mod_security is disabled for this domain. It's not completely incompatible with TB if it is set up exactly right but the standard general rules tend to wreak havoc. During development it should always be disabled. Clear your local browser cache & cookies and/or use an incognito mode tab to work on & test your site. Local cache can also have weird and unexpected impacts when making changes to the site itself. Run the Core Updater and make sure you have all the latest updates for 1.1.x Bleeding Edge. Make sure you do not accidentally downgrade to 1.0.x which is the default action if you have not run Core Updater before. Downgrading will wreak massive havoc on your site... Consider disabling non-Thirty Bees modules (`Advanced Parameters -> Performance`) and see if the problem goes away. Go to `Preferences -> SEO & URLs` and regenerate the .htaccess file. If you have made any additions to this file try commenting them out. Are you running Apache? Make sure the conf.d for your domain is set up properly. In particular I have found that setting `Require all granted` for the public_html directory is necessary on my server. Are you running Nginx by itself without Apache at all? That requires some special setup to make work with TB. That's what comes to mind that I would try right away. I hope something there works for you, too.

I'm testing with the PayPal sandbox right now to make sure payments go through and that I can match PayPal transactions with TB transactions after we download both via APIs. Looking at the PayPal Sandbox Account page for a recent test transaction the PayPal Transaction ID shown is 82L077085W384201H as can be seen here: However when looking at the TB Back Office (and in the tb_order_payment table) the saved PayPal transaction ID for this order is PAYID-LWVBSRI76V28173WT268073A: These numbers do not match. The number shown by PayPal is the actual Transaction ID for the payment. The number shown in TB however is the PayPal Payment ID. The difference is that in PayPal one Payment ID can have multiple Transaction IDs but each Transaction ID only refers to a single transaction. This causes a few problems: If you know the Transaction ID you can work backwards to the Payment ID via the PayPal API but knowing the Payment ID does not mean you can isolate a single Transaction ID. I can't yet test on the live PayPal server but at least on the Sandbox system PayPal does not support searching for transactions using the Payment ID. They do bring back a single result if you search for a Payment ID but clicking on it doesn't do anything. Just takes you back to the summary page. You can't search your emails from PayPal with a Payment ID, but if you have your Transaction ID you can paste it into your email system and it will immediately bring up the PayPal email. Basically the Transaction ID is what PayPal uses to refer to individual transactions (payments, refunds, partial refunds, chargebacks, etc) and it should be the ID that is saved in the TB database. It would be really ideal if both the Payment ID and the Transaction ID could be saved but if using the standard order_payment table there is only space for one. So, IMO, it should be the Transaction ID getting saved rather than the Payment ID. If I go ahead and make this change (assuming I can figure out how to do it...) will there be any negative repercussions that I have not considered? @datakick, @lesley, any ideas? Thanks in advance for any assistance.