Welcome to the changelog section of Freemius, here you'll find our weekly technical update notes. You can subscribe to all posts via Newsletter or follow us on Twitter to stay updated.
We noticed a bug where creating a new SaaS from the Developer Dashboard would incorrectly show the business model option, asking whether to create a Free plan.
In this deployment, we removed the choice, since it was not intended.
Following up on last week’s announcement, today we are marking the checkout phase2 as production-ready.
The deployment comes with a few improvements too.
While the new checkout is production-ready, we have not yet made it the default. The old checkout will still show up unless you have specifically opted into the new system with checkout_style: 'phase2' JS parameter. For more information, please read our announcement post here.
We noticed a bug in the old checkout where the form could not handle some errors in rare cases. We have deployed a fix for the same.
It has been a couple of weeks since we pushed updates to the new phase2 checkout and this week, we are starting to push it for production. Like before, we will do it gradually, without breaking any custom CSS you might be using. Please read on below to learn more.
We first released the phase2 checkout on May 20, 2024. Since then there have been a few iterations and improvements.
Today with a few more bug fixes we are finally marking the checkout as release-candidate and preparing for the production switch.
phase2 checkout the default in production. However, if you have a custom checkout CSS for the phase1 checkout but not for the phase2 checkout, we will keep on showing the phase1 checkout for you.checkout_style=legacy to force load the phase1 checkout.phase1 checkout.Until the rollout
checkout_style=phase2 in the URL parameter or JS snippet. More on it later in.phase2 checkout.Starting today, you will notice that your existing checkout CSS style (if any) has been moved to the “(Legacy) Custom Checkout CSS file” under the plans page of the Developer Dashboard. The first input field is now empty.
To migrate your CSS for the new version, simply put the stylesheet URL in the first input field and you are good to go. Please read our documentation to learn about CSS customization.
We would be glad to get your help to test the new checkout out in the wild.
Kindly go to the plans page and toggle the new configuration to get URLs and JS snippets to load the new checkout.
Alternatively, you can just add checkout_style=phase2 or checkout_style: 'phase2' in the URL or JS snippet to see it live. Here are some live demos:
If you find any issues please get in touch with our support.
We will make another announcement in July when we believe the checkout is ready to go into production. Until then, please stay tuned.
We are bringing a few small enhancements and bug fixes to the phase2 checkout (beta).
We are also getting ready to rollout the new checkout in production. Please read our announcement post here.
We are rolling out various SaaS-related improvements and tweaks to our Developer Dashboard and marketing automation system. Please find the details below.
Our Developer Dashboard is heavily tuned for WordPress.org products (plugins, themes, add-ons, etc). It has many pages, such as Deployment, Integration, etc., that are only relevant to a WP product. It also shows several notices and pop-ups for the SDK integration.
All these features have no meaning for a SaaS product and can create confusion. So we have improved the system by scoping those features only for a WordPress product and keeping the SaaS interface clean.
We introduced the option to create a SaaS product from the Developer Dashboard a while back. But we didn’t allow changing an existing product to SaaS yet. A few of our partners have already been using our platform to facilitate their SaaS products. We have been asking our partners to use the “Plugin” type for SaaS products while we manually adjusted the platform to their specific needs. This gave us enough time to learn the specific necessities for SaaS and improve our system accordingly.
Now that we have rolled out many platform improvements, we are opening up the settings to change your product type to SaaS. Simply navigate to the Settings page of your product from the Developer Dashboard and you can change the type from there.
We have made some more improvements to our marketing automation system to use the right terminology and phrases when dealing with a SaaS product.
From the User Dashboard, we offer a way for the buyers to upgrade their subscriptions. One would simply need to navigate to a subscription from the “Renewals & Billing” page.
Previously the list was showing different options ordered by the quota of the licenses. This resulted in items with heavy pricing showing up on the top of the list, which could discourage the buyer from exploring other cheaper options. This issue was reported to us by a partner.
To fix this, we are now ordering the items showing the cheapest plan and pricing first and then gradually moving towards more expensive options.
With this week’s deployment, we are bringing some small yet meaningful enhancements to the Developer Dashboard. Please read below.
We’ve been showing a small notice under the store page to mention the list of products the data is relevant for.
This notice can become overwhelming for stores with many products, taking up much real estate. Our partners suggested that we introduce an option to remove the notice. In this update, we did just that. Now you can click the close icon to make the notice disappear and it will not appear again under the same browser.
We’ve been offering migration services to partners coming from different platforms like EDD, CodeCanyon, ThemeForest, etc. We not only offer the first-time migration of payments, subscriptions, licenses, etc, but we also do ongoing sync for incoming payments from the subscription of the previous platforms. We do this to give a seamless licensing experience to the buyers.
As an advantage, partners can see the existing subscriptions and associated payments in the Developer Dashboard. But we understand the list can become confusing when there is a mixture of Freemius-sourced entities and migrated entities.
To solve this, we have introduced a new icon in the columns, which will indicate whether the entity came from Freemius or the old platform. Please note the icons will show up when there are any migrated entities to save real estate.
We have pushed various updates to the beta checkout. Just like before, to try it out, use checkout_style=phase2 in the URL parameter or checkout_style: 'phase2' in the JavaScript integration. If you’ve missed the various updates to the phase2 beta checkout, you can find it here and here.
We have three kinds of discounts we show in the checkout before the subtotal.
The reason we show all these discounts is to encourage the purchase of a higher billing cycle, licenses, or bundles.
But over the year we received feedback from our partners asking us to give the flexibility to determine which discounts are to be shown. There are cases where a huge discount can discourage a buyer. For example, if a seller is providing 100-site pricing, then it can often result in an undiscounted price of $10,000, whereas the amount to pay could be less than $500.
So in this update, we are not only giving the ability to turn off discounts through configuration but also remade our discounting system from the ground up, making it smarter. Please find below the three newly introduced configuration parameters and their different values.
| Property | Description | Accepted values | Default value |
|---|---|---|---|
annual_discount |
Determines whether the annual discount will be shown in the checkout. | true | false |
true |
multisite_discount |
Determines whether the multi-site discount will be shown. When the value is auto, the discount will only be shown if the single license pricing difference does not exceed 10 times more than the current pricing.
For example, say you have single-license pricing at |
true | false | 'auto' |
'auto' |
bundle_discount |
Determines whether the bundle discount will be shown. The bundle discount itself depends on the compound price of its children. By default with maximize, we try to take the compound price from the lowest billing cycle and license. But with the value of true, we take it from the closest billing cycle and licenses.
While introducing this parameter, we also deprecated the old |
true | false | 'maximize' |
'maximize |
Please do give the new discounting system a try. The new system is meant to be backward compatible. The only exception is that the multi-site discount can be turned off depending on the pricing. You can always set a hard value of true to enable it back.
Here are some examples and live demos you can check. Feel free to modify the URL parameters.
We have also introduced three new UI parameters to give more flexibility.
always_show_renewals_amount (true | false, default false)
When set to true, a small line mentioning the total renewal price per billing cycle will shown below the total. By default, it only shows up when there is a renewal discount involved. We introduced this option because it can help provide more context with different discounts already shown in the UI. For example, one can see that there is a 30% annual discount and wonder if the discount is only for the first payment. There could also be a coupon that is applicable for the first payment only. With a clear line mentioning the renewal amount, the confusion goes away.
show_inline_currency_selector (true | false, default true)
We recently introduced an inline currency selector in the total line. Now you can hide it if you want by setting the value to false. We gave this option, because in some cases, the seller may not want to show an UI to change currencies for various reasons.
refund_policy_position (below_form | below_breakdown | dynamic, default dynamic)
Many partners asked us to give the option to specify where to place the refund policy badge. For some partners, there were no reviews, so placing it below the breakdown instead of the form was the natural choice. For some products, the breakdown area can be slim (without discounts or upsells). So by placing the UI below the breakdown optimizes the real-estate.
We realized we cannot decide the best positioning because it depends. So we are giving full control over where you want to place the refund policy UI in the horizontal dual-column layout. Depending on your preference you can place it below the form or the breakdown. We recommend using the default value dynamic. Depending on the width and height of the page the UI will be placed optimally either below the form or below the breakdown.
Please note when there are no reviews, the badge will always be positioned below the breakdown. Also this settings has no effect for mobile or single column view.
We are super stoked to announce that we have kickstarted the LiteSDK project. The LiteSDK is meant to be a lightweight alternative to our classic WordPress SDK. It will have minimal features, for example, license activation, software updates, etc. We aim to make the project as modular as possible, to gradually add features that can optionally be included in a WordPress product.
To ease the communication layer of the LiteSDK, we have introduced two new endpoints in our API.
/v1/plugins/:plugin_id/activate.json (public)
Use this endpoint to activate a license on a new or existing site. It expects the following required parameters:
license_key – The license keyuid – A unique identifier of the siteUID: The generation of the UID must be done by the client. More on it later.
Optionally it also accepts the following parameters:
url – The URL of the sitetitle – The title of the siteversion – The version of the WordPress plugin/theme.install_id – The ID of an existing install/site (must belong to the same user and must have the same UID when it was created).On a POST request, with the above parameters the endpoint can
first_name, last_name and user_email parameters.Upon success, it returns the id, public_key and secret_key of the user and the install entities.
/v1/plugins/:plugin_id/deactivate.json (public)
Use this endpoint to deactivate the previously activated licenses on an installation. It expects the following required parameters:
uid – The same UID used when activating the licenseinstall_id – The ID of the install from where you want to deactivate the licenselicense_key – The key of the license you want to deactivateOn a POST request, the endpoint will deactivate the license from the install entity. It will return the properties of the install entity on success.
We have created a POC (Proof-of-Concept) of a WordPress project demonstrating the new endpoints. This POC is still under heavy development and we are yet to write documentation. But if you want to take a look, you can visit our GitHub project.
The project has the following features at the moment:
uid parameter.Over time, we aim to turn it into a proper LiteSDK that can be used in production. At this stage, please help us identify more use cases by trying out the POC in your projects. We are always listening to understand how we can make our products better. If you need help trying out the POC, please get in touch with our support. You can also “watch” the project under GitHub to subscribe to updates.