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.
Go to the “Payments” page and you will see the “Download” button. You can choose to download all payments or just the ones showing up in the UI.
While Freemius offers intensive reports and analytics tools, the export feature is beneficial for understanding the data and doing your custom reporting. Please stay tuned while we introduce such export options for more assets.
Our Developer Dashboard has a dedicated page where you can get instructions and configure different parameters for our official WordPress SDK. We noticed, that over time the page got bloated with much information.
To simplify it for first-time users, we have refreshed the page. It now holds the necessary information ordered first and links to our documentation where it dives deep into the details.
We are glad to announce the new phase2 Checkout is officially in production starting today.
We’ve been doing a gradual rollout for quite some time and the time has finally come for the first production rollout.
If you do not use custom CSS to modify the Checkout, then the new Checkout will start showing up for you without any changes.
However, if you are using custom CSS, then you have until August 18th to migrate your CSS. You can read about the features, migration tips, and full rollout schedule here.
Frequently Asked Questions (FAQ)
I have migrated CSS and put a new URL under Customization, but the new Checkout is still not showing up, why?
Please note that after you’ve migrated your CSS, you will need to clear the field of the “(Legacy) Custom Checkout CSS file” under the “Customization” section of the “Plans” page. Only then will the new checkout start showing up everywhere (on the User Dashboard and inside the WP SDK).
Can I have more time to migrate my CSS?
From August 18th, we will set the new Checkout as default. However, you can force-load the old checkout with checkout_style: 'legacy' in the JS configuration. Please note that you will have until September 29th, after which we will completely remove the legacy Checkout. Also, you cannot force the legacy Checkout on the User Dashboard and inside the WP SDK.
How can I have the option in the Checkout to switch to a monthly billing cycle?
We removed the billing cycle UI from the Checkout and have introduced the “Upsells” concept. Therefore, when the Checkout is loaded with an Annual billing cycle, we do not show the UI to downgrade to a Monthly billing cycle.
However, you can use the configuration option show_monthly_switch and set it to true to show it anyway.
What are the new configurations available to tweak the Checkout UI
You can find them here inside our JavaScript SDK documentation.
In yet another improvement for “Freemius for SaaS”, we are pushing the ability to expose license keys to the buyers. During our previous update, we removed the license keys for SaaS products. We thought license keys were not relevant for SaaS. However, after having some discussions with our makers, we understood, that for some SaaS it is preferred to expose license keys. It becomes handy when a subscription is canceled mid-term and you want to keep the features active until the license itself expires.
So in this iteration, we are giving the option to show license keys to customers for SaaS products.
Go to the “Settings” page from your Developer Dashboard. You will find a new section labeled “License Keys”. From there you can enable or disable the visibility of license keys for your customers.
If this is disabled, then none of the payments or subscription emails will have the license key-related information. By default, this setting is disabled for SaaS products. If you want your customers to see the license keys, then please enable this configuration explicitly.
We are glad to announce that the Spanish translation of our Checkout is out of beta.
Long ago we introduced translation capability to our Checkout. Displaying the checkout in the buyer’s local language significantly boosts the conversion rate. At that time we used AI to generate the following translations for the Checkout:
Spanish
German
French
Italian
Dutch
But we marked the translations as “beta” as those were not proof-read or approved by professionals.
Now we have started to hire professional translators to finalize the translation and the first language to go through the process is Spanish.
Passing the language parameter with an auto value to the Checkout ensures that if your buyers are from Spanish-speaking regions, the Checkout will automatically load in Spanish. You can also pass static values like es to the language parameter. See here for an example. When the Checkout is loaded in a different language or when the language parameter is present, we show a dropdown in the footer of the Checkout to change the language.
More information about it can be found in our documentation (search for “language”). Very soon we will finalize more languages. Please note that only the languages for the new phase2 Checkout are being worked upon. Just a reminder on August 4th, we will switch the phase2 Checkout as default. You can read more about it here.
This week we are also deploying some enhancements and bug fixes for the Developer Dashboard.
Improved “Custom localhost URLs” UI from store
When viewing a user from a Store, we have improved the “Custom localhost URLs“ section to include instructions on how to change it from the relevant product.
Previously we allowed changing it directly for the product associated with the latest license of the user. Since a user can have licenses for multiple products from a store, it created some confusion. To avoid such confusion, we have improved the UI to tell explicitly what action needs to be taken and for what product.
Bug fix for the new product form
We noticed a bug in the “New Product Form” when it was loaded directly due to some race condition. We have deployed a fix for the same.
Analytics bug fix
We noticed that for some makers, the store-level analytics were generating some API errors. We identified the root cause and have deployed a fix.
Minor Checkout enhancement
We noticed some redundant API requests being made from our Checkout when calculating taxes. We have pushed a fix to make the system more efficient while making network requests.
We made some noticeable UI/UX overhauls to the Licenses page in your Developer Dashboard. We wanted to add a new action item in the table and while doing so, we noticed that over the time, the table UI has gotten bloated with many actions.
So we took the opportunity to make some refreshing changes.
Refreshed Licenses table with consolidated actions
We replaced some old designs and components inside the licenses table.
For example, we removed some space between the columns and used a new component to display the license key with the copy and reveal button.
We grouped all available actions, which are non-frequent, at the end of the column inside a dropdown menu.
We hope this change will help you make the most use of the table, by showing the most important things at first.
New action to copy renewal link
Sometimes customers ask our makers to share some links from where they can renew expired licenses or update billing methods. We do provide a User Dashboard from where your customers can self-serve. But sometimes sharing a direct link helps in quicker conversion.
To help you quickly generate such links, we have added a new action item beside every license row. Simply click on the “Copy Renewal Link” button and share the link with your customer. This will open the checkout with the license key prefilled from where they can update the renewal mechanism.
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.
We have optimized various UI and UX as it has gone through many QA tests.
We identified a bug where some strings were not translated and have fixed them.
The form focus and validation experience have also been improved.
Rollout Strategy
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.
Bug fixes for the old checkout
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 below to learn more.
Recap: Beta releases so far
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.
Gradual rollout
On August 4th, 2024 we will make the 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. Only when you clear the Custom CSS from the legacy section, the new Checkout will show up by default.
On August 18th, 2024 two weeks after the production rollout, we will enable it for everyone. However, you will still have the option of using checkout_style=legacy to force load the phase1 checkout.
On September 29th, 2024 we will completely remove the legacy phase1 checkout.
Until the rollout
You can switch to the new checkout by using the configuration checkout_style=phase2 in the URL parameter or JS snippet. More on it later in.
You now have two different CSS configurations, one for the existing checkout and one for the new phase2 checkout.
Custom CSS migration
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.
Remember to clear out the (Legacy) Custom Checkout CSS file after you’ve migrated to have the new checkout show up by default.
Call for testers
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:
Fixed some edge case bugs when navigating between products of the same store could lose the current context.
Fixed a regression in the Tax Refund form, for old payments. The “Yes – Refund” button stayed disabled in some cases even after filling out the form. We have fixed this issue.
We are rolling out various SaaS-related improvements and tweaks to our Developer Dashboard and marketing automation system. Please find the details below.
Removed unrelated features from the Developer Dashboard
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.
Introduced the option to change a product’s type to SaaS
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.
Improvements to our marketing automation
We have made some more improvements to our marketing automation system to use the right terminology and phrases when dealing with a SaaS product.
We use tools, such as cookies, to enable essential services and functionality on our site and to collect data on how visitors interact with our site, products and services. By clicking CONTINUE, you agree to our use of these tools for advertising, analytics and support
