The Official ExpressionEngine Add-on Store

Any thoughts on this Derek? Will it be possible for me to make Ansel available to download and trial and then they can purchase and be off to the races?

Sure, you could use what we’re calling “Editions” internally to have a free download, and another item that is purchased. I suppose the question is, what criteria are you using to indicate a valid license? Are you comfortable with that boolean API moving to our own methodology, or is it something you’d rather continue using your in-house methods for?

basically a reseller of my products. So I do business with them, not with the actual end-user/buyer, which lets me circumvent all the VAT hassle.

Yep, that’s why we structured it this way. We’re the seller of record for your add-ons, and we’ll be using TaxJar to automatically calculate and collect VAT, so it handles the icky math and inscrutable tax codes. Your payout would be a commission from us, transferred instantly to your Stripe account. The only VAT you would be responsible for is your own business’s VAT responsibility related to your revenue, we cover the costs and transfers for the customer’s VAT.

As for what I’d love to see is the ability to gift licenses, look up valid licenses, possibly transfer licenses from devot:ee to the EL store.

Those are all good ideas, and probably in reverse order of our priority for implementing. As a developer do you have access to all of the licenses you have sold on devot:ee to be able to transfer to the official marketplace?

So downloading legacy versions is a no-no?

If there turns out to be a large need, it would be simple enough to add additional files for separate legacy version downloads. Ideally I’d like to keep it simple though. Do you have add-ons that are regularly being downloaded for an older version, where packaging the older versions in your download doesn’t make sense?

> Sure, you could use what we’re calling “Editions” internally to have a free download, and another item that is purchased. I suppose the question is, what criteria are you using to indicate a valid license? Are you comfortable with that boolean API moving to our own methodology, or is it something you’d rather continue using your in-house methods for?

I reckon I’d have to see how it all works. I don’t think I’d be particularly averse to checking with your API vs mine.

Probably for launch, the simplest thing is to let devs who have invested in their own verification systems to keep using them. Once we move to in-app purchases and updates, it’ll make more sense to consolidate it. Does that sound reasonable to you?

Seems reasonable to me.

> Your payout would be a commission from us, transferred instantly to your Stripe account.

Ah okay, so I need a Stripe account, which I haven’t got at the moment.

> As a developer do you have access to all of the licenses you have sold on devot:ee to be able to transfer to the official marketplace?

I can do a lookup of a license number, yes. I can also search on name/email of the license owner, which helps me locate a purchased license.

Devot:ee also has an API so I can retrieve sales info and store that locally. That helps me to create an archive of sales, too. I use that to generate stats and graphs etc.

> Do you have add-ons that are regularly being downloaded for an older version, where packaging the older versions in your download doesn’t make sense?

Well, I found people often need a legacy version. For the newest version, you need a valid and up-to-date license (the customer needs to renew their license every year), but legacy versions are always available for download, even with an expired license.

Well, I found people often need a legacy version. For the newest version, you need a valid and up-to-date license (the customer needs to renew their license every year), but legacy versions are always available for download, even with an expired license.

Ok so if I understand correctly, the difference is that your add-on requires a subscription for continued access to the current release, but you want to allow downloads for previous versions even if they do not keep that subscription active. Is that right?

Yeah, but I’m not married to that setup, so to speak. 😊

Well, I found people often need a legacy version. For the newest version, you need a valid and up-to-date license (the customer needs to renew their license every year), but legacy versions are always available for download, even with an expired license.

Ok so if I understand correctly, the difference is that your add-on requires a subscription for continued access to the current release, but you want to allow downloads for previous versions even if they do not keep that subscription active. Is that right?

If this is being considered, we’d like to request that it’s a per-developer setting as we do not allow legacy downloads of our software for expired licenses (except for some add-ons where the previous developer’s license agreement conflicts). Legacy software could cause extra support load for bugs already fixed if the consumer doesn’t want to pay for the updated version. They’re buying a license to the software and they have a year from the time of purchase to download it. If someone needs a legacy copy, we handle that on a case-by-case basis and send it to them directly.

Echoing Jace’s comment. I’d rather not offer the option to download previous versions and handle it with the customer directly. The only reason I’d send an old version is if they have a convincing case not to use the latest one, and even then I’m clear in mentioning that it is not supported. I don’t like the idea of providing access to old versions to customers at their will.

Reading the replies, I’m not sure Devot:ee actually offers access to the legacy downloads for expired licenses… Probably not. Disregard my remark about that, then. 😊

I agree. I only offer legacy versions on request where I can make as clear as crystal directly with the user that legacy versions are unsupported.

Concerning legacy downloads as a front end person (who buys quite a few!).

It’s always handy to have a previous version available. Sometimes you may be stuck on the previous EE version which the latest addon version doesn’t support. So if you need to update, because of say a bug fix, then not offering them can delay fixing a broken site.

Ideally I’d like to have the option of getting the most recent previous release directly from the store, even if it’s just the ability to download the files with no support. If it’s a case of contacting the developer directly, as Brian suggested, yeah that’s ok, the main thing is that there’s a method of getting the addon if needed.

Rob, in which cases like this would you not have a backup of the unmodified download that was procured for the client matched to their app version?

Rob, in which cases like this would you not have a backup of the unmodified download that was procured for the client matched to their app version?

Derek,

Take this scenario to try and explain my thinking:

Site is running an older version of EE(x) and was built a while back

EE(y) is current but for various reasons the site can’t be upgraded to that version yet

Site is updated to the latest release of EE(x) but the addon breaks due to a bug

The addon has a later release for EE(x) which fixes the bug, but the latest addon version for EE(y) isn’t compatible with EE(x)

…that’s when having a previous version could be useful!

Yes you could roll back, pre update, but if the earlier version of EE(x) has security issues which need attending to that’s not good.

Obviously I’m hoping that with EE5 and future versions things will be a lot more stable with 3rd party addons, and most addons will mostly just work with future EE versions (within reason!). Of course when doing an EE version upgrade then updating addons at the same time is best practice and we do that whenever possible.

In an ideal world we’d all be running the latest versions of everything, but life ain’t like that 😊