30knees

Thank you! I've now changed to {categories:/}{id:/}{rewrite} from {categories:/}{rewrite}. Under "Redirect to the canonical URL" I have the recommended 301. Does this mean that the change from the old schema to the new schema is communicated as a 301 redirect to search engines or do I have to add this to the htaccess file myself?

Nice! I like the module. I think it's helpful. I currently I track such things in a spreadsheet. One suggestion: It would be great if it could work with combinations. All our products are combinations. Maybe other users have lots of combinations, too. The idea of a list of all products displaying profit margin information is great. Maybe the list could also reflect how special prices impact the margin. One thought: Mass update of products price is also offered by the "forum member tool" Prestools and of course also by your Datakick module, so I personally see less value for that at the moment unless lots of supporters don't have any of those modules.

Very nice, I'll try this. Yes, orders from Amazon have "amazon" in the domain. Thank you!

Hi, Is there a way to turn off order confirmation emails for a certain type of payment method? Background: We use Baselinker to import orders from Amazon. I'm guessing because Baselinker is based in Poland, all order confirmation emails are being sent in Polish, even if it's Amazon.de or Amazon.es. Seeing these are Amazon orders, we don't need to send any order confirmation emails in the first place. If not by payment method, maybe by email address? Or by method of order creation (eg here via import)? Thanks

The mailalert.php is correct in my store but I am still unable to edit some subjects. What is the solution? I get: No Subject was found for bankwire in the database.

You could disable all modules and enable them one by one to see which one is causing problems. Perhaps there's a more efficient method to check that someone else can comment on.

@datakickI've experimented in 1.5. From what I can tell: Changing a category works. The old URL redirects successfully. Changing friendly URL does not work. The old URL does not redirect successfully. Changing the schema to eg {categories:/}{id:/}{rewrite} from {categories:/}{rewrite} works. The old URL redirects successfully. Is this correct or should changing friendly URL also work?

Do you get any errors relating to [unit_pricing_measure]? We get them and I'm wondering whether tb supports this unit somehow. We use the datakick module to connect to Google Merchant.

We only use one currency and that works. I can't comment on a multi-currency setup.

Thanks for your thoughts. It sounds like a schema like {categories:/}{id}-{rewrite} would be the best of both worlds.

Some comments: Are we renting tb itself or the non-essential premium modules? Would you be willing to pay a large up-front sum (say a lifelong membership) instead of renting? Have you considered that the buying vs renting depends on the nature of the software? Some types of software need to be maintained/kept current. Other types not. Also, there are opportunity costs involved: Would I rather spend 1000 now or 20 every month? This depends in part on what I can do with the money I have now cash in pocket by going the rental route instead of the buying route? You're not just renting (after a certain membership level). You're also buying monthly support. About one's own work and efforts being used (also) for someone else's profits ... well, that's a different thing. I don't know how I'd feel about this move IF I could and had actually contributed like datakick does. But I can't and I don't. Philosophically, I'm fine with subscription models if you get something back. I'm all for open source but I'm also realistic enough to see that not every open source model is going to survive unless it's driven by at least one person's passion. I don't think anyone here is maintaining their shop because it's a passion independent of economics.

I think you can safely uninstall the theme you do not want. Just be sure any customisations (such as translations) are also migrated to the new theme.

A further suggestion would be to be able to rearrange the order of the FAQs.

I think it's a good move because tb needs to generate income if tb is ever to become more than just Smile's side-project that his business benefits from and we all mooch off of. I'm still, unfortunately, skeptical about whether tb can grow sufficiently to attract third-party module developers or even enough so datakick gets some additional support. But I wish the project all the best.

I'm not sure but did you check the product.tpl file in your theme folder?

Many, many months later I'd like to follow up. :) Apple Pay (still) doesn't work for me. I don't see it in the settings of the module and I don't see it in the checkout when I'm on an Apple device. Is it working for others?

For example, I see a Braintree module in the admin backend that does not exist in the marketplace.

Would it be possible to expand the module such that there's an admin section to see all FAQs and where they are? Kind of like the CMS section. I think this would make the FAQs much easier to maintain.

The support hour for certain member groups is very nice and much appreciated. I hope the nice Premium modules and the support lead to lots of supporting members! How do we "place an order" for the included support? Can members donate their hours to a certain common goal, say adding a certain functionality (only if the donated hours are enough for that month, of course)?

Has this been implemented in 1.5?

If you click "Add question" before clicking "Save" your text will disappear!

Yes, if someone truly has a single supply case it's not easy! One would have to be able to manually specify whether it's a single supply or individual supplies and for the former what the tax rate should be. At least in my shop I can't come up with a single supply case, any bundle would be two separate ones. I would assume that's the case for most goods. A combination of services or good and services is more likely to lead to a single supply, in my opinion. Here one more quote to help figure out question of single supply vs two or more individual supplies: There is a single supply where two or more elements or acts supplied by the taxable person to the customer are so closely linked that they form, objectively, a single, indivisible economic supply, which it would be artificial to split (Levob Verzekeringen and OV Bank, paragraph 22; Case C‑425/06 Part Service [2008] ECR I‑897, paragraph 53; and Bog and Others, paragraph 53). There is also a single supply where one or more elements are to be regarded as constituting the principal supply, while other elements are to be regarded, by contrast, as one or more ancillary supplies which share the tax treatment of the principal supply (see, in particular, CPP, paragraph 30; Levob Verzekeringen and OV Bank, paragraph 21; and Bog and Others, paragraph 54 and case-law cited). Para 28 in https://curia.europa.eu/juris/document/document.jsf?text=&docid=134105&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=434078

I think it depends on the nature of the pack, unfortunately. If it's just a special offer pack, I believe it's correct that there should be two products, each with their own VAT rate, because the products are not intimately connected, there is no "primary" component and "secondary" component. However, if the pack is a "true" pack, then the "primary" / "principal" part of the pack detemines the VAT rate of that pack as a whole. The pack as a whole is a distinct product from each separate component. This understanding comes from this Court of Justice of the European Union case: https://curia.europa.eu/juris/document/document.jsf;jsessionid=651CFF8D09C8073D9D6742F60B327FD1?text=&docid=198525&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=384011 Paragraph 21 on the nature of the pack: As a preliminary point, it should be noted that, according to the Court’s case-law, where a transaction comprises a bundle of elements and acts, regard must be had to all the circumstances in which the transaction in question takes place in order to determine whether that operation gives rise, for the purposes of VAT, to two or more distinct supplies or to one single supply (see, to that effect, judgments of 10 March 2011, Bog and Others, C‑497/09, C‑499/09, C‑501/09 and C‑502/09, EU:C:2011:135, paragraph 52 and the case-law cited, and of 21 February 2013, Žamberk, C‑18/12, EU:C:2013:95, paragraph 27 and the case-law cited). The Court's ruling on one VAT rate where the above analysis leads to the conclusion that there is "one" supply/product: The Sixth Council Directive 77/388/EEC of 17 May 1977 on the harmonisation of the laws of the Member States relating to turnover taxes — Common system of value added tax: uniform basis of assessment, as amended by Council Directive 2001/4/EC of 19 January 2001, must be interpreted as meaning that a single supply, such as that at issue in the main proceedings, comprised of two distinct elements, one principal, the other ancillary, which, if they were supplied separately, would be subject to different rates of value added tax, must be taxed solely at the rate of value added tax applicable to that single supply, that rate being determined according to the principal element, even if the price of each element forming the full price paid by a consumer in order to be able to receive that supply can be identified.

Quantities (incl. of combinations), too!

Datakick has mentioned that some 1.7 modules can be quite easily adapted to 1.6/tb. I don't think it's possible to "make sure" new modules for PS 8 work on tb. The two systems are diverging more and more. It's just how it is. It doesn't look like tb will gain enough critical mass so external developers will start working on it, unfortunately. That means you're limited to tb modules and to any 1.6/1.7 modules that will work with tb, perhaps with some tweaking.