New Pricing Page Coming Soon, License Activation Improvements, Bug Fixes and More!

In addition to everything mentioned below, this release has many small fixes that we patched during the last 7 months. So, we highly recommend updating your plugins & themes to use this release.

License Activation Improvements

Bundles License Activation

If you are selling bundles with many products that users typically use in parallel on the same website, it is not very pleasant for customers to activate the same license key for each product in the bundle.

To improve this user experience, we introduced new logic that checks if a license is associated with a bundle and automatically activates the license key for all the other bundle's paid products installed on the site that are not yet associated with a license key.

To activate this capability, you'll need to add the following to the SDK init snippet params:
'bundle_license_auto_activation' => true,

We decided to release this option as turned off by default because it may lead to some confusion in the following scenario:

• A freelancer purchased a bundle license
• They install pluginX on their client's site and activated it with their bundle's license key
• The client installs pluginY independently, while pluginY is also part of the bundle
• If the option is turned on, the license will be automatically activated for pluginY, unexpectedly utilizing a license of the owner without them knowing about it

In the next iteration, we'll enrich the mechanism to auto-activate the license if it hasn't yet been flagged as white-labeled.

Improved cURL Error Handling

Even though WordPress' HTTP API is supposed to work with web sockets, some users still encounter cURL errors when the cURL module is missing or disabled by the host. Instead of showing the cURL error number, the SDK will now display an informative human-friendly error message that explains the issue and guides the user about how to fix the situation with their host.

Themes

• The activation process of a theme that doesn't have a settings page in the WP Admin was fixed.

• We addressed all the errors that were thrown by Theme Sniffer and Theme Check.

Affiliate Application Form

With our legal firm's help, we recently developed an affiliate agreement that we and our partners can use for onboarding affiliates. If you are leveraging the in-dashboard affiliate form, you'll notice that we added a new checkbox requiring users to accept the terms and conditions of the program before they can apply:

Getting Ready for the new ReactJS-based Pricing Page

Freemius’ current in-dashboard pricing page was developed back in 2015. Obviously, the page has undergone extensive development since then, as we’ve added many features throughout the years. However, the front-end technologies it uses are already outdated, making maintenance, bug fixing, and new feature development much slower.

While we still haven't replaced the pricing in the SDK, this version introduces the required infrastructure to start using the new pricing page right away, which is pretty stable.

The new pricing page is much "smarter" and facilitates many pricing use-cases we haven't supported before.

As the new pricing page is open-source, it gives you complete flexibility to modify it as you wish, which hasn’t been possible until now.

Removing _fs_blog_admin & _fs_network_admin from Heartbeat Requests

Due to WordPress limitations, when a WP AJAX call is invoked, there's no way to identify if it was initiated from the WP admin area or the site front. As a workaround, we came up with a simple technique by adding a querystring argument _fs_blog_admin=true (and _fs_network_admin in the WP network admin) to all WP AJAX calls initiated from the WordPress admin area, which then allows us to identify if a request was triggered from the WordPress admin area or not.

WordPress has a keepalive mechanism (Heartbeat API) that initiates a WordPress AJAX POST request every few seconds when the user is logged into their WordPress admin area. The querystring param was also added to those requests.

Troubleshooting website issues frequently involves checking the network tab. Naturally, seeing many requests with a Freemius "fingerprint" (_fs_blog_admin=true in the querystring) generated lots of false-positives where admins and hosting companies assumed that those frequent AJAX requests were triggered by the SDK, when, in 99.99% of the cases, it had nothing to do with the SDK. Regardless, we optimized the logic a bit, and now it skips from "touching" the keepalive AJAX requests.

Adding rel="noopener noreferrer" to Relevant Links

We reviewed the entire SDK and added the noopener and noreferrer attributes to all applicable external links generated by the SDK.

Reducing the SDK Size

As part of our efforts to reduce the SDK size, we enriched .gitattributes to exclude all the *.po translation files from the downloaded ZIP file from GitHub. *.mo files are the actual binary translation files that are in use by the SDK. This exclusion reduces the SDK by ~900Kb.

Chinese Translation

Huge thanks to @xiahengchen for translating the entire SDK to Chinese 💯
Xiaheng Chen is a new member of our development team specializing in frontend development.

Version Contributors

• Leo Fajardo - @fajardoleo (Lead)
• Vova Feldman - @vovafeldman
• Xiaheng Chen - @xiahengchen
• David Gwyer - @dgwyer
• Dovy Paukstys - @dovy

Official release notes: https://freemius.com/blog/release-notes-new-pricing-page-license-activation-improvements/

Opt-In / Out Enhancements, User Change, and More

Tracking Permissions Enhancements

In the past year, we received a healthy amount of criticism accusing Freemius of being some sort of spyware. The funny part is that other competing eCommerce products collect almost the same data that Freemius does after activating a license key. However, we have the most transparent opt-in and license activation forms that explain exactly what is collected, when, and how, so it’s naturally much easier to criticize what can be seen :)

The WordPress ecosystem is a “wild-west” when it comes to data collection and opt-in permissions. Competing solutions don’t have a consistent approach for developers to obtain legal approval for data sharing of their user information. With our opt-in process, we’re increasing transparency and privacy controls, so, if you know or use Freemius, you already know that all of those allegations have nothing to do with reality. Regardless, since this is a recurring issue, we decided to make some changes to address the concerns raised by some community members.

Opting out from data collection in the paid product version

One of the main concerns raised by users is that there’s no option to opt-out in paid products integrated with Freemius. That was indeed the case by design. We believe that receiving update notifications and the ability to upgrade a plugin/theme version directly through the WP Admin are essential capabilities. If a user misses a security update, their site can be at risk. Regardless of our explanation, some users don’t seem to agree with us, so we decided to end this fiasco and expose the opt-out option in paid products. We made sure to add a clear warning explaining why ongoing connectivity with the licensing and updates engine is essential, leaving the decision up to the user:

Opting in/out from tracking plugins and themes

A while ago, we enriched the SDK to track basic info about installed plugins and themes for opted-in users. The goal was to enrich the Developer Dashboard with insights about plugins and themes that are commonly used with your product to empower you with data to help you make sure your product is compatible with the top plugins/themes it’s commonly used with, help you handling support more efficiently (e.g if you know your product is working badly with one of the user’s installed products), and for other business reasons like establishing collaborations and partnerships. Unfortunately, we never had the chance to complete the indexing and visualization of this data as we kept prioritizing other features, so it does not yet appear in the Developer Dashboard.

In the last few months, we’ve received numerous support requests from users and developers asking to offer a way to disable this type of data collection. Once we realized that tracking plugins and themes can be problematic for some users, we quickly introduced a workaround with two special defines (WP_FS__TRACK_PLUGINS and WP_FS__TRACK_THEMES), allowing admins to turn the plugin and theme tracking off by setting the defines to false in the wp-config.php or functions.php files. That solved the problem for some time, but wasn’t good enough.

I’m excited to share that the new SDK release - 2.3.2 - comes with enriched opt-in and license activation forms that easily allow the user to control the tracking of plugins and themes. Plugin & theme tracking has been moved to a standalone permission that can now be selectively enabled/disabled during opt-in and license activation:

The opt-out dialog has been enriched too, so users that already opted-in will be able to disable plugin & theme tracking without completely opting out.

Collaborative Privacy Document

We have compiled and thoroughly addressed all the privacy and data tracking concerns we have heard about Freemius over the years into a single document. The goal is to have a public document that you’ll be able to reference when any of your users have privacy concerns related to Freemius. We are going to maintain the document “source” on GitHub, making it a collaborative document and keeping the editing process and versioning transparent to show we have nothing to hide. By leveraging the power of our entire network, we’ll be able to craft a much more accurate and richer document that addresses everyone’s concerns. You’ll also be able to submit PRs with questions and concerns that we may have missed or issues that may be raised in the future.

If you’d like to help us resharp the document, please check it out at the link below:
https://github.com/Freemius/data-concerns-faq

You are more than invited to branch it and submit a PR with your edit suggestions.

Account User Change

In previous versions of the SDK, when a user activated a license key for a freemium product after they had previously opted into usage-tracking in the free version, the Account page would remain associated with the information of the user that opted into the free version, regardless if the license belonged to the same user or if it was a “foreign license” that was purchased under a different account. This logic was created by design, allowing larger organizations to keep billing issues separate from their development teams.

Following the recent migration of OceanWP to Freemius, we had the opportunity to work with a very large customer base of agencies and freelancers - people who are building websites for clients. In many cases, agencies will buy paid plugins and themes needed for a project and will continue maintaining the website for some period after it’s completed. So, if the client installed the free plugin/theme version and opted into its usage-tracking, the client’s account remained associated with the installation and the agency couldn’t see nor maintain the website from their User Dashboard, even if they purchased the license for the paid product version. We discovered that users find this behavior confusing, leading to support tickets asking us to switch the user associated with the installation to the license owner.

We solved this problem by adding a special mechanism where users can now easily transfer the ownership of the Account and the product install to the license owner.

When a “foreign license” is activated, you’ll notice a new Change User button next to the User ID. Clicking it will open a dialog box that shows a list of masked email addresses associated with the account. Then, simply choose the email associated with the user you want to transfer the ownership of the account to and click the I Agree - Change User button to complete the transfer:

In the case of a product with add-ons, there could be multiple email addresses displayed when there are multiple add-ons that were activated with licenses that belong to different owners.

We also enriched the license change/update dialog box so that when entering a license key that is associated with a different owner, a new checkbox will be dynamically displayed allowing you to associate the account with the license owner:

Please note: Due to the complexity of the logic to support this capability, the initial release does not support changing the user on the network-level Account page. That use-case will be supported at a later stage.

Misc

• The Japanese translation files were updated from ja_JP to ja as that's the locale WP is using for Japanese.
• Changed the Cancel button style in the Deactivation Feedback Form from primary to a secondary button.
• Fixed a bug related to updating a license in a free product version.
• Enriched the debugging page with an extra column for the licenses list showing if the license is set to white-labeling.
• Fixed a caching issue to properly remove references to SDK versions that are no longer exist in the local environment.

Official release notes: https://freemius.com/blog/opt-in-permissions-privacy-transparency-payout-notifications/

License Security, Cloned Environment Fix, Tabs Navigation, and more!

License Security

One of the most useful things that came out of OceanWP’s migration to Freemius was that we discovered some exciting needs for Agency customers. We’ve added 2 new capabilities into the User Dashboard to allow for greater protection of the license purchased by an Agency, including White Label Mode and URL Whitelisting.

From a marketing/sales point of view, these features make your products much more compelling for that special segment of users that are building sites for clients.

Both features are available in a new LICENSE SECURITY section shown when managing licenses:

White Label Mode

Agencies and freelancers who work on client projects can hide confidential information about their account and license by flagging a license as White Labeled. This means that Account details normally shown in the Account tab in the WP Admin will not appear when Users check the box that says “This license is activated on my client(s) site(s)”. This addition to the User Dashboard is great for anyone who uses your product as part of their own services. Here’s everything that will be hidden when a license is set as white-labeled:

• User information
• Billing details and invoices
• License key
• Pricing page
• Add-on prices (if you sell add-ons)
• Contact Us page

URL Whitelisting

With the new URL whitelisting capability, customers can also control the URLs that can activate their license or continue receiving updates.

Cloned Environment – Finally Fixed!

If you’ve been using Freemius for a while, there’s a good chance you already stumbled across the dreaded fatal PHP error: Argument 1 passed to Freemius::get_api_user_scope_by_user() must be an instance of FS_User.

This error has been “haunting” our support for a while, but we’ve never managed to reproduce it on our end. After months of troubleshooting and research, we identified the problem:
The symptom of the error was due to inconsistency in the serialized object types stored in the Database. For some reason, instances of our custom classes, such as the FS_User, were converted into instances of the generic stdClass class.
The error was typically happening after some sort of website cloning (e.g. website migration, staging to production replication, etc.).
The environment was running PHP 7.2 and higher.

With the help of several kind buyers, we got screen recordings of their cloning process, which helped us to reproduce the issue and pinpoint the exact code that was causing the issue (this is one example from BackupBuddy):

if ( is_a( $data, '__PHP_Incomplete_Class' ) ) {
    $serialized_object = serialize( $data );
    $std_class_object  = preg_replace( '/^O:\d+:"[^"]++"/', 'O:' . strlen( 'stdClass' ) . ':"stdClass"', $serialized_object );
    $data              = unserialize( $std_class_object );
}

Due to the way those cloning solutions work the plugins are not included in the cloning execution process, therefore when the options are unserialized and replicated, PHP 7.2+ considers those object instances as __PHP_Incomplete_Class, which is then converted to stdClass and stored incorrectly in the Database.

To make a long story short, we created a workaround by wrapping all the logic that is expected to load instances of our classes from the storage with a helper function that will convert those instances to their corresponding classes in case they are serialized incorrectly as stdClass.

Tabs for Plugin/Theme settings!

With the new SDK release, developers can choose to include Freemius pages in the WP Admin within tabs of plugin or theme settings instead of menu items on the WP side menu. To activate the “tabs” view please include the following line in your WordPress SDK integration snippet:

'navigation' => 'tabs',

New Translations

100% Translated to Tamil – big thanks to Sankar Srinivasan!
76% Translated to Czech – big thanks to vyskoczilova!

Noticeable Bug Fix

After users updated a premium version of a theme from the Updates page in the WP-Admin, it was still showing as if the theme was running a previous version even though the update was successful. This was all due to a cached layer, and the issue is resolved. Thanks to Jesse and Yuli from REI Conversion for bringing it to our attention and helping us test!

Keep Up to Date

You can stay up to date by subscribing to our blog, and you can also check out some of our previous release notes so you can see progress on different Freemius features.

Official release notes: https://freemius.com/blog/white-label-mode-url-whitelisting-user-dev-dashboard-upgrades-coupon-improvements/

Beta Program, Bundles, Multisite Network, Add-Ons, and more!

Release Cycle Management – Beta Program

The whole release cycle in the world of WordPress plugins and themes is lacking compared to the robust CI/CD workflows in the “real world”. If you have a plugin/theme with tens of thousands of active installs, every release becomes risky. At the least, it can negatively affect your business agility and puts your users’ and customers’ websites at risk. There are various practices to mitigate that risk, and one of the more popular ones is building a group of beta testers: People that love getting early access to your products – and giving them a spin before anyone else in exchange for feedback.

So… we are pleased to announce that you can now systematically onboard beta testers with Freemius and release beta versions only to those users that opted-in to the beta program!

Users can opt-in to the beta program directly from their Account page by simply checking a box and agreeing to the disclaimer prompt:

Alternatively, you can add a user to the beta program directly from the user’s profile in the Developer Dashboard (don’t forget to click the UPDATE button to save):

Ready to release a beta version? Not a problem! Just upload it to the DEPLOYMENT section and flag it as a Beta release. When you’re ready to make the beta release public for everyone, simply switch the version to Released – it’s that easy!

Beta releases will be flagged in the WP Admin with a Beta label, making it clear to users that they are currently using a beta version of the product:

We hope that by empowering you with the ability to easily start beta programs it will create a safer product environment for the whole WordPress community, and of course, for your customers. Now you can test releases on a small subset of users who willingly opted-in to test your versions before making them public for all.

Notice: The initial version of the Beta Program feature can only be activated for users that are running a paid version of your plugin/theme. Also, it is not yet supported for add-ons.

Bundles

If your main business model is offering a free core plugin/theme and then selling bundles, we have some exciting news for you! You can now render the bundle’s pricing inside the WP Admin instead of showing the plugin/theme’s pricing. To activate that option all you need to do is add a 'bundle_id' => '<YOUR_BUNDLE_ID>', setting to your integration snippet – it’s that easy!

Moreover, when activating a paid plugin or add-on, if the opted-in user obtained a bundle license that includes that paid plugin/add-on, the license will now be automatically activated upon the activation of the product. In a multi-site network environment, the license will only get activated if the license’ activations have enough unallocated licenses to activate the license for all of the subsites in the multi-site network.

Multisite Network

When we originally enhanced the SDK to include a proper multisite network integration, due to the complexity in the storage data model, we decided to ignore the scenario of a plugin activation being switched from the network level to the site-level, and vice versa. I.e., network activation of a plugin, and then later on, deactivation and activation of the same plugin on the site-level.

The new SDK version is backward compatible and now fully supports the handling of those use-cases. It may seem simple, but there’s a lot of thinking that had to go into the logic behind it. For example, if a paid network-integrated plugin is site-level activated on 3 out of 10 subsites in a multi-site network, and the super-admin activated a license on all those 3 sites, if the plugin will be shifted to network activation, the super-admin is automatically redirected to the license activation screen, but only required to activate a license on the 7 out of the 10 sites remaining which never had that plugin activated before.

Just to give you some numbers, there are about 40 different use-cases involved in that transition, and we handled all of them! (hope we didn’t miss any)

In addition, for plugins that have different WP Admin menu settings on the site level vs. the network level, you can now specify the network level menu settings by setting the new 'menu_network' => array( … ), option in the SDK integration snippet.

Auto-Install – Disabled

Unfortunately, after ongoing discussions with the WordPress.org plugin review team, we had to disable the auto-install capability, which we introduced back in March 2017 after Jetpack started to support installation of non-wp.org themes. I’m not going to start #WPDrama because indeed our implementation was not exactly the same as Jetpack’s. It’s just a shame that creativity and UX are being blocked in some cases like these and for no good reason.

Since we are a data-driven company, when we released the auto-install feature, we wanted to validate our assumption that the auto-install experience is actually better for users. So, every user that selected the auto-install option during checkout was sent an email with a simple Google Form survey to rank the install experience from 1 to 5 and provide additional feedback. Out of 686 responses, 83% ranked it as excellent, another 10.5% ranked it as great:

We clearly see the need for simplifying the whole upgrade experience, and we’ll get back to tackling this problem from a different angle in the future, while making sure to comply with wp.org guidelines.

Support Forum Link

If you don’t have a free version of your product on WordPress.org (and therefore no free support forum) or just want to link the Support Forum menu item added by the SDK to another support page, we introduced a new filter to override the URL. You can implement it as follows:

<?php
    function set_my_custom_support_url( $wp_org_support_url ) {
        return ‘https://my-awesome-product.com/support/forum/’;
    }

    my_fs()->add_filters( 'support_forum_url', ‘set_my_custom_support_url’ );
?>

Account Billing & Invoices

As part of our ongoing efforts to make it easier for customers to access their billing information and invoices, we introduced a little link in the upper area of the Account page:

Even though the billing & invoices can be found on the lower part of the same page, some buyers were still missing it, so we added this simple anchor link.

Download/Install Add-Ons from WP Admin

Back in 2017 when I attended PressNomics 5, I had a chat with my friend Matt Cromewall. Among many different things we discussed, Matt mentioned Crate (which was never released btw) as an example of a great UX for managing and installing add-ons from right within the WP Admin, without the need for customers to go through the standard, tedious installation process normally offered by WP plugins and themes:

[Crate early prototype from cratewp.com]

This feature has been on our list for more than 2 years, and we’ve finally managed to prioritize it! This is particularly useful if you sell a lot of add-ons. Now your customers can easily download or activate your add-ons directly from the WP Admin.

So how does it work?

If the customer has a valid license for an add-on and they are running the free wp.org version of your core plugin/theme, they will now be able to download the add-on directly from within the WP Admin, in addition to viewing the add-on’s details:

Installing the add-on directly within the WP Admin from wp.org compliant products is not allowed, therefore, the install option will only be available when the installed & activated core plugin/theme version is paid or explicitly flagged as non-WP.org compliant. This is how it will look in that case:

We’ve made another UX improvement to the WP Admin add-ons section: Installed add-ons are now shown with an INSTALLED label, making it easier for admins to know if an add-on is already installed on the website or not:

Compatibility with ManageWP, MainWP, InfiniteWP, and Jetpack

The Freemius WordPress SDK incorporates a mechanism that automatically identifies a plugin or theme’s main file. That mechanism relies on debug_backtrace() and assumed that WP core is responsible for originally including that main file. After several related GitHub issues in which the SDK was failing to properly get the product’s title and version, we did some troubleshooting of the problem and found that it was related to the use-case of 3rd party plugins being responsible for inclusion/execution and not th...

Keep-Alive, Gutenberg, Add-Ons, and Bug Fixes

Important Bug Fixes

Fix for a Conflict with WordPress Websites Management Solutions

We optimized the logic that programmatically identifies the caller’s product main file to support environments that run services like ManageWP, which intervene in the theme/plugin’s inclusion mechanism. Previously, when a site was running a service such as ManageWP, the SDK would fetch ManageWP's agent plugin version, instead of the version of the actual plugin, which would cause conflicts with the updates mechanism. Due to that bug, if a site was running an agent plugin version that was newer than your upcoming version, the (previous) updates mechanism would "think" that a newer version of the product is already installed, and an update would, therefore, not be served via the WP Admin. On your next release email, we recommend adding the following paragraph:

ManageWP / InfiniteWP / MainWP User?
Due to a conflict found between those services and the SDK which we are using to serve updates, if you are eligible for automatic updates and you don't receive an update notice for the product in your WP Admin during the next 48 hours, you'll need to get it manually. Log in to https://users.freemius.com/downloads, download the latest release, deactivate and uninstall the previous version, and then install and activate the newest release. This is a one time manual operation, and once you update to the latest release with the fixed SDK the updates will start working automatically again. Apologies for the inconvenience and we appreciate your patience.

Fix of The Multisite Networks Storage Model

We identified a bug in the SDK's storage model on multisite networks. After a bunch of testings, the fix for the bug should not break any backward compatibility. BUT, if your product is commonly used on multisite networks, kindly spend some extra efforts on testing the new SDK with your product. We would recommend releasing a beta version with the SDK update to a few multisite customers first, before releasing it to the rest of your customers.

Gutenberg

Avoid conflicts between admin notices and the new Gutenberg editor by hiding all notices on Gutenberg-powered pages (thanks @alanef for the PR).

Reference: 8a87d38

Add-Ons

Freemium Add-Ons

Disabled the SDK's software updates and custom readme.txt mechanism on the WP Admin's plugins and themes search pages to avoid conflicts with freemium add-ons. This change is particularly relevant when the site has a plugin/theme that has a freemium add-on with a free version on WordPress.org activated.

After Opt-in Redirection

The SDK now supports custom first-page/getting-started redirection after an opt-in/skip.

Caching & Updates

Due to the recent changes we made in the SDK's updates mechanism, which now supports custom readme.txt files for your paid versions, if there's no newer version than the one installed on a given site, our RESTful API endpoint returns the 404 HTTP error - not found. We spotted several environments that, for some reason, were not handling 404 errors gracefully, triggering the WordPress updates mechanism to keep checking for updates on almost every page view in the WP Admin. To tackle that, we enriched our caching layer to cache the result of requests that generated a 404 HTTP response in order to avoid slowing down the site and exhausting the API.

Reference: c725cf0

Keep-alive Mechanism

In previous releases, the SDK would send weekly updates only if there was at least one change in the tracked metrics. So, if the API didn't receive any requests from a plugin/theme for six months, it was impossible to determine whether the product is still active or if for example, the admin had deleted the product using FTP. As we strive to provide more accurate information on the sites that are using your WordPress plugins and themes, we have introduced a weekly keep-alive mechanism which will trigger an API request at least once a week, regardless of whether or not any updates occurred in the tracked metrics. Not only will this enable us to empower you with better analytics, but it also allows us to optimize different commercial and marketing mechanisms which your users and customers benefit from. For example, if a user has subscribed for your paid product and the purchased license is only activated on a site that didn't send a keep-alive for more than 30 days, then the renewal reminder notice will be different and require the customer to take action by choosing if they would like to go ahead with the renewal, or cancel. In case they don't take any action (e.g. ignore the email), the subscription will automatically be canceled one week before the renewal.

Admin Notices

The admin notices template was enriched to indicate the slug and the type of product it is associated with. For example, if your plugin's slug is awesome-product you can now target and customize all the notices that are added by the SDK using the following CSS rules:

.fs-notice.fs-slug-awesome-product.fs-type-plugin {
    // Custom CSS rules.
}

Reference: 516a9b2

Bug Fixes

• Properly include static resources (JS, CSS) even when the plugins/themes folders are customized (i.e. the plugins are not in wp-content/plugins/).
• Hide the Upgrade tab for freemium themes that only sell add-ons without having a paid plan of the theme.

Localization

• A new translation of the SDK to Hungarian (thanks @Surbma!).

Critical bug fix for 2.2.1

Fixed a critical bug that was causing a PHP error when activating a product with SDK v2.2.1 while there was already a product with an older SDK running on the site.

Premium Changelog / Readme.txt, Custom Premium Slug, Subscription Cancellation

Important

Please notice that if you have a freemium plugin on Freemius that has a paid version (free plugin + paid add-ons doesn't count), and like to utilize the full power of the new SDK, the integration snippet requires an update. Your updated code needs to look like that:

<?php
    /**
     * Plugin Name: My Very Awesome Plugin
     * .....
     */

    if ( ! defined( 'ABSPATH' ) ) {
        exit;
    }

    if ( function_exists( 'my_fs' ) ) {
        my_fs()->set_basename( true, __FILE__ );
    } else {

        // ... Freemius integration snippet ...

        // ... my plugin's code ...

    }
?>

It has to be integrated into the plugin's main file. If you like to include it in a different file, make sure to replace the __FILE__ with the absolute path to the plugin's main file.

Premium Changelog and readme.txt

I’m pleased to share that you can now create a custom readme for your paid product version, and the new WordPress SDK will pick that data up from our API. This was on our list for quite a while and we have finally managed to prioritize it. These are great news for premium only product owners: now you can finally show your readme’s content in the WP Admin, including changelog changes.

Like with everything we do, we try to build the best mechanism to save you time and avoid duplicate work. After some brainstorming we decided to follow the same pattern of auto-generating the readme.txt files dynamically, using special Markdown-friendly syntax. If you have a premium-only product, you are all good. Just write your readme.txt as you would. If you have a freemium plugin or theme, you’ll only need to have a single readme.txt file (yep, that’s right!), it will include all of your data. For premium-only content wrap it as follows:

[//]: # fs_premium_only_begin
 
Whatever goes in here will be only in the premium readme
 
[//]: # fs_premium_only_end

For content that should appear only in the free version, wrap it as follows:

[//]: # fs_free_only_begin
 
Whatever goes in here will be only in the free readme
 
[//]: # fs_free_only_end

Content that will not be wrapped in neither of the above will simply appear both in the free and premium readme.txt files.

Please notice that it will only work for new deployments that include the new version of the SDK. You can learn about the version deployment mechanism in general, and the new premium readme.txt support here:

https://freemius.com/help/documentation/selling-with-freemius/deployment/

Custom Premium Slug / Folder-Name

Due to historical reasons, whether if you have a freemium product or a premium one, our deployment mechanism would automatically add a “-premium” suffix to the product’s folder name. This convention was essential for making the upgrade process of freemium products more user-friendly, so they could install and activate the paid product version without the need to deactivate and uninstall the free one. But this was far from optimal:

1. Premium-only products had to have a redundant “-premium” suffix in their product’s folder name.
2. Over the years, we learned that many freemium themes are using “-lite” as the suffix for their free WordPress.org slug. In those cases, the deployment mechanism would generating awkward theme folder names like “awesome-theme-lite-premium”.
   Drums…

You can now fully customize your premium version folder name! And also customize the “(Premium)” suffix that we add to the premium version product’s name. You can do both in the SDK INTEGRATION section in the dashboard:

IMPORTANT:

If you already have customers that are using your paid version and would like to rename it, to avoid any PHP errors during the update process, you’ll have to do it incrementally by releasing 2 new versions:

1. The 1st release should remain with the same default premium slug and will needs to include the newest SDK which comes with a special mechanism that supports folder renaming.
2. Then, customize the premium slug and release the 2nd version (minor version). Our updates mechanism will make sure that the 2nd release will only be available for users that are already using the latest SDK, the one that supports renaming.

Terms of Service Update

We updated the URL of the “Terms of Service” link shown in the opt-in screen:

Instead of linking it to our general website’s terms, which leads to some confusion among admins, it is now linked to your product’s specific usage tracking “terms” page that detail all the information about the usage-tracking and collected data:

https://freemius.com/wordpress/usage-tracking/<productID>/<productSlug>/

When running the premium version, the link label is now changed to “EULA” and its URL refers to the auto-generated EULA for the product:

https://freemius.com/terms/<productID>/<productSlug>/

Support Forum Link

The optional submenu item that links to the WordPress.org support forum now opens on a new page. This was a repeating request so we finally prioritized it 😉

Subscription Cancellation

From a consumer point of view, being billed for a subscription renewal unexpectedly is a real pain. Not only is it annoying, it requires the user to “work” to get their money back. Money that, in theory, shouldn’t have been taken from their account in the first place. Moreover, it drives negative emotions like anger and frustration and affecting the way a consumer perceives your business. From the business owner’s point of view, it means dealing with angry customers, which is mentally hard and not the fun part of the business. So you end up wasting time on “refund support”, that could be invested in the actual product or into helping customers that have real problems.

Therefore, we are constantly trying to come up with techniques to eliminate those unexpected charges, saving you, the seller, the time and the emotional hassle of dealing with those issues. As well as making the experience of customers that buy products through Freemius as pleasant as possible.

In the last year, we discovered two use-cases in which some customers assume that the following actions will also cancel all of their future billing:

1. Deactivation and uninstallation of the product
2. Deactivation of a license (without cancelling its subscription)

This assumption actually makes a lot of sense, as this is how things are working with most online services (SaaS). If you deactivate your account, the subscription will (usually) be canceled.

To avoid this confusion, when a user is about to deactivate your plugin/theme and it’s associated with an active subscription with a license that’s only been activated on that website, before showing the deactivation feedback form, the SDK will now prompt the customer and let them cancel the subscription, as part of the product deactivation sequence. This is how it looks like:

Similarly, when the user clicks on the license deactivation option from their Account page, if the subscription license has only been activated on that site, we ask the customer if they would also like to cancel the subscription, in addition to deactivating the license:

We are aware that it will most likely increase the subscriptions churn a bit, but it will save you time and hassle, as well as have a positive effect of your brand. If users will feel more confident when buying your products because you are using Freemius, that’s a win-win-win for everyone.

After Purchase Notice

The after in-dashboard purchase admin notice was enriched. Instead of immediately guiding the customer to download and install the premium code base, the logic now first checks if the premium version is already installed on the site. If it is, instead of guiding the user to download and install, simply suggest to activate it with a single click:

Translations – Dutch

The SDK was fully translated to Dutch! Huge thanks to Benny Vluggen, Mike van der Sluis, and Patrick Buntsma. The SDK is now translated to:

• Spanish
• Dutch
• Italian
• Japanese
• Hebrew
• Russian
• Danish

If your native language is not English and you have a high-level of English, please join our translations efforts to help us maintain the current translations and translate it into new languages:

https://www.transifex.com/freemius/wordpress-sdk/

Freemium License Activation & Deactivation

Prior to this SDK release, when a user would upgrade a freemium plugin/theme directly within the WP Admin, our WordPress SDK would automatically take care of the license activation in the background. But, if the user would purchase the paid version from your site (outside the WP Admin) and would have already opted-in/skipped the opt-in in the free version before, they would have to activate the license by clicking on the “Activate License” link, either on their Account page (if they ever opted-in), or on the plugins/themes page. Basically, there was no clear path or instructions for the customer on how to activate the license, which usually generated a support ticket.

So now, after installing and activating a paid version of a freemium product, even if the user had...

Multisite Network Bug Fixes

Multisite Network

• Since all plugin/theme updates are done on a network level, allow updating a plugin/theme in a network environment even if the license is activated on a single sub-site.
• Fixed the Last updated value shown in the product's information when clicking the View details link.
• Added several new subdomains to count as staging sites.
• Fixed an edge case that was throwing the following PHP exception on a network admin:
  Fatal error: Uncaught TypeError: Argument 1 passed to Freemius::get_api_user_scope_by_user() must be an instance of FS_User
• Also, added a new button the debugging page to force a data-type migration, for networks that face the issue mentioned above.

Usage Tracking

• Fixed some of the event tracking related to the automatic install process when upgrading within the WP Admin (relevant for freemium products).

PHP7 Compatibility

• Minor fix of clone usage that is no longer allowed in PHP7 (82cdedd)

Translations of the Premium Version, Add-Ons Visibility, and Bug Fixes

Translations 🇮🇹 🇬🇧 🇯🇵

Since the auto-generated premium product version by Freemius has a -premium suffix at the folder name, WordPress.org translations will not be loaded. Therefore, we've enriched the SDK for freemium plugins and themes that have a free version hosted on WordPress.org to seamlessly download and use the proper translations from the repo.

Add-Ons Visibility 🔌 🧙

You can now control which add-ons will be visible in the in-dashboard Add-Ons page in the WP Admin. You can either control it from the ADD-ONS section of the parent plugin:

Or directly in the SETTINGS page of an add-on:

Notable Bug Fixes 🐞

• Major: Fixed the logic that fetches the new GDPR marketing flag in the premium version during license activation.
• Hide the license activation and upgrade/purchase buttons from the Account page for add-ons that don't have paid plans.
• The in-dashboard pricing and checkout pages are now properly rendered on iPhones (Safari iframe related CSS bug).