Skip to content
Choose a tag to compare
  • Updated translation files to fix placeholder issues in PHP 8.
Choose a tag to compare
  • PHP 8.1 compatibility fixes.

Thank you @matczar for the PR 🙌

Choose a tag to compare


Merge pull request #545 from Freemius/feature/2.5.0-rc.2-linear-secur…


Reapply security patches on develop branch for 2.5.0-rc.2 tag
Choose a tag to compare
Merge pull request #544 from Freemius/feature/security-fix-master-2.4.3

Security fix on top of master for 2.4.3 tag
Choose a tag to compare

Call for Testers

Even though we ran thorough testing of all kinds (automated, manual, and regression tests), and while we feel pretty confident in the stability of 2.5.0, due to the complexity and amount of code changes & use-cases involved in this version, we decided to push it as a release candidate first.

"I want to be involved in testing - how can I help?"

Want to help us in testing? That's great and appreciated!

  • If you are running a beta program, simply update the SDK to this RC and push a new version as a beta.
  • If you are not running a beta program and know that some of your customers running cloned environments like staging to production, or using your plugin/theme with WaaS plugins like WP Ultimo, when they contact your support due to SDK issues you can send them a special version of your product with this SDK as it should solve their problems.

Regardless, if you try out the RC, whether you experience issues or, on the contrary, if it resolves the SDK problems your users were facing before, please let us know! Simply contact us via, open a GitHub issue, or use any other communication channel that is easiest for you - we want your feedback :)

Duplicate Websites and Clone Resolution

With the growing popularity of WaaS (WordPress as a Service) networks and hosting companies that provide 1-click staging to production deployment workflows, you’ve probably already dealt with customers complaining about unexpected issues when site duplication is involved.

In short, a clone is a website (or a subsite) that has a unique ID and pair of public/secret keys that were assigned by Freemius and are identical to the ID and keys of another website. You can learn more about clones, how they are typically created, and when, in this doc.

Inspired by Jetpack's UI, I’m excited to share that this SDK release comes with a fully-featured clone identification, management, and resolution mechanism. It’s a capability that’s been on the back-burner for quite some time, and I highly encourage you to familiarize yourself with the clone websites problem and how the WordPress SDK handles it to get the most out of the enhancement:

Deactivation Feedback Form UX Enhancements

Snoozing for Troubleshooters

While our deactivation feedback form offers a unique opportunity for users to provide feedback to product owners before they abandon, over the years we’ve heard complaints that users really hate the feature. After analyzing the feedback, we managed to attribute this sentiment specifically to the ‘troubleshooters’ segment.

Plugin updates are a common task that website maintainers have to deal with on a daily basis. Sometimes a plugin/theme update can go wrong due to conflicts, bugs, and incompatibilities, causing issues and unexpected errors on a site. Maintainers usually don’t dive into the code level, so the common troubleshooting process is to identify the cause of the problem with plugin deactivations and reactivations, followed by theme switching. Meaning, you need to deactivate the plugins one by one until the problem is resolved, then reactivate them individually and in the same order that they were deactivated. In theory, this should help isolate the ‘problematic’ plugin, but if it doesn’t uncover the issue then the next attempt should be a ‘theme switch’.

As the ‘footprint’ of themes and plugins that use our WordPress SDK grows, the deactivation feedback form adds an additional click to each deactivation. From there, reactivating a Freemius-powered plugin automatically redirects to the opt-in screen or to the plugin main settings page (based on the opt-in state), which adds another click to navigate back to the plugins page.

This means that just 5 plugins using Freemius on a site can potentially add 10 extra clicks — something that’s understandably annoying for troubleshooters. And when managing 20 sites, as an example, all those clicks accumulate over time, which explains why some maintainers really dislike the WordPress SDK.

Having understood the reasons behind the ‘hate’, we came up with a simple solution to relieve the ‘pain’ for troubleshooters and, hopefully, win some of their trust back.

The Feedback Form already displays an option that indicates a deactivation is temporary for troubleshooting. So, instead of just sending that feedback our way…

  1. We now show an option to snooze the panel from one hour to 30 days.
  2. Because we realize it doesn’t add any value to product owners, choosing to snooze skips sending feedback to Freemius altogether.
  3. Finally, if the admin snoozes the form, the redirection will be off for the snoozed period.


Snoozing will only impact the current logged-in admin and will work across all Freemius powered plugins and themes installed on that website.

This improved UX can potentially save tons of clicks for ‘heavy’ troubleshooters, and we are excited to see the difference it will make.

Enable Deactivation with Empty ‘Other’ Feedback

To encourage users to submit feedback you can act upon, previously, when a user selected the ‘Other’ option in the deactivation feedback form, the ‘Submit & Deactivate’ button’s state was changed to disabled until the user entered some input to explain the ‘other’ reason.

It was brought to our attention that this UX was problematic because users read from top-left and some choose that option because they simply don't want to provide any feedback. I.E., if they choose that option before noticing there’s an option to ‘Skip & Deactivate’, it gives the impression that it’s impossible to deactivate the product without providing any feedback.
Now, when the ‘Other’ option is selected and the explanation box is empty, the button is enabled and labeled as ‘Deactivate’:


And, obviously, no data will be sent to our end because empty ‘Other’ feedback is useless.

Anonymous Feedback Default Checkbox State

If a user skipped the opt-in and chose to provide feedback using the deactivation feedback form, by default the feedback was not anonymous to allow you to contact the user if needed. This version of the SDK introduces a new filter so that you can control the default submission mode of the feedback form and change it to anonymous feedback by default, using the following:

my_fs()->add_filter( 'default_to_anonymous_feedback', '__return_true' );

User Assets Ownership Mix-Up — Gone!

A healthy percentage of WordPress plugin and theme purchases are made by ‘builders’, where eventually the project is handed over to their client. To facilitate the relationship, we offer a good amount of flexibility to allow changing ownership of account assets from one person to another.

Without diving into the technicalities, with the many millions of websites running our SDK, we stumbled upon several edge cases that unexpectedly mixed up assets between accounts. While these issues were infrequent, it’s painful for the customer, for you, and for us to fix.

If there was a contest for the most annoying and time-consuming issues, this one is the undisputed winner of 2020–2021 🏆 It’s also a good example of where giving too much flexibility without trying to foresee all of the use cases (and you never will) can cause more damage than good.

Not only did we add some restrictions in the backend to reduce the instances of the issue, the new WordPress SDK release enhances the Account’s email update experience with additional input from the user, and handles each case slightly differently:


Fix of HTTP 404 Not Found (AKA ‘No Updates’)

Some of you may have received support tickets where customers complained that the SDK is throwing errors and slowing the system down, typically with a complementary screenshot of an error from Debug Log (or other debugging plugins).


The HTTP errors were returned when there were no newer releases, which is the expected behavior of a proper RESTful API implementation when a resource doesn't exist.

Since it’s not trivial to understand that this behavior is expected until contacting us, and it generated unnecessary support tickets for you (and us), we have modified the HTTP response code to 200 to eliminate this confusion once and for all. This API change was already deployed several weeks ago, so there's a good chance you’ve noticed this type of complaint has disappeared.

Looking back, we now acknowledge we should have made that change much earlier. It's just that sometimes the ‘right’ technical thing isn’t ‘right’ for the end user.

Fault Tolerance to Background Connectivity Issues

A few weeks ago AWS had a temporary downtime. As we host our servers on Amazon, naturally, the downtime caused connectivity issues to our API server. The websites that their Freemius sync cron was executed during that period were added with a dismissible notice about the connectivity issue, causing a bunch of support inquiries from concerned users. The purpose of the notice is to highlight ongoing connectivity issues due to firewalls, ISP blockages, etc. It’s not made for temporary connectivity issues. Therefore, we improved the logic by putting a fault tolerance mechanism in place, so the notice will only be added after 3 consecutive failed connectivity attempts (typically 3 days).

Resolution of Deprecated Multisite Network Functions

wpmu_new_blog() and deleted_blog() were deprecated in WP 5.1, which was throwing a notice when running in debug mode. We updated the multisite integration to instead use wp_insert_site() and wp_delete_site() correspondingly when running on new WordPress releases. Thanks Dario Curvino for your contribution 🙌

New Filters

We introduced a new hide_freemius_powered_by filter to allow you to hide the Powered by Freemius tab from the pages generated by the SDK:
my_fs()->add_filter( 'hide_freemius_powered_by', ‘__return_false’ );

And another filter named hide_billing_and_payments_info to hide the billing and payments history shown by default to customers in the Account page:
my_fs()->add_filter( hide_billing_and_payments_info’, ‘__return_true’ );

Official release notes:

Choose a tag to compare

License Activation Enhancement

This release introduces several small, yet powerful, enhancements for the license activation screen. These annotations below go over each detail of the optimizations we’ve made, with details outlined below.


  • The Hey {{ firstName }}, was removed to clean up some space.
  • The welcoming message has changed from Thanks for purchasing {{ producTitle }} to Welcome to {{ producTitle }}, to be more... welcoming 🙂
  • The updates & licensing mechanism disclaimer was adjusted to a more inclusive form.
  • A tooltip was introduced next to "" to explain the relation of the plugin/theme and Freemius.
  • The permissions overview trigger was merged into the disclaimer and is now triggered by the "diagnostic data" link.
  • The ADMIN NOTICES permission was removed since there's not much value in showing it for paid products.
  • We realize that some people are very emotional about the plugins & themes permission even though it can be easily switched off. While there is a lot of value in collecting it, since it's not mission-critical and probably the most dreaded capability among our data practices, the option is now turned off by default when activating a license key.
  • To reduce concerns even further, we added tooltips to all of the permissions to explain why they're needed.
  • We've recently documented known license activation issues (with solutions) in our knowledge base, so, to save customers time and reduce your support load, we added a new License issues? link to this document right after the license activation button. If you prefer to copy the documentation to your knowledge base and link to that instead, you can use the known_license_issues_url filter.

This GIF showcases the updated license activation screen behavior:


Beta Programs

Just before we entered 2021, we discovered an issue in our implementation of the Beta Program functionality, and, therefore, temporarily paused delivery of beta releases. We've fixed the implementation, and this SDK version is now integrated with the fixed mechanism.

How to migrate beta users to the new mechanism?

First of all - you'll need to update the SDK to this latest version.
Then follow these instructions:

  • Sign in to the Developer Dashboard and navigate to the USERS section of the relevant product.
  • Change the filter to only show Beta Participants:
  • Click DOWNLOAD USERS to get a CSV of all users who previously enrolled in your Beta Program:
  • Finally, you'll need to send a message asking them to join the beta program again from the site(s) in which they want to receive updates with beta releases. Here's a copy you can use for your message:
Hi {{ firstName }},

Thanks again for being part of our Beta program and helping us test/improve/shape {{ producTitle }}.

Apologies for the hassle, but due to an issue that was discovered in our Beta releases mechanism, if you'd want to keep getting updates with Beta release, you'll need to enroll in the Beta program again.

If you are no longer interested in being part of the Beta Program, simply ignore this message.

Pricing Page

The SDK comes with a special mechanism to automatically use the newest version of the SDK available, whether it's included in your plugin/theme or in other Freemius-powered plugins/themes installed on a site.

We recently discovered that even if you haven't integrated our ReactJS-based pricing page, and another plugin/theme on the same website did, it was unexpectedly showing the new pricing for your product too.

Until we fully migrate to the new pricing page, we’ve updated it to only show up for products that include the build files in their product's code, even if there's another product running a newer version of the SDK.

Add-Ons Opt-In Behavior

To maximize the opt-in rate to usage-tracking, previously, activating an add-on would trigger the parent product's opt-in screen, even if the user had already skipped it before. After receiving some feedback, we realized this approach can be annoying, especially for products that usually need multiple add-ons installed just to get started.

We adjusted this behavior and from now on free add-ons inherit the opt-in state of their parent product.

Official release notes:

Choose a tag to compare

License White-Label from the WP Admin

One of the more exciting features we released with version 2.3.1 is the option to white-label a license when it's activated on a client's site:


This feature helps make your products more compelling for professional "builders," people who build websites for clients.

It's a fantastic capability, and we are getting lots of positive feedback on it. But many users are not aware of this option, which can lead to frustration and unnecessary support tickets.

To overcome that flaw in UX, we are excited to share that we brought that option right into the Account page in the WP Admin, where a builder most likely realizes they need it.


We hope this new admin notice will improve your customers' experience and eliminate those support tickets altogether.

jQuery Update

WordPress 5.5 no longer supports deprecated methods using jquery-migrate, so all usages where replaced with jQuery.on(). Thanks, @sc0ttkclark, for the PR!

Plugin Activity Status Identification Fix

As some of you may have already noticed, we have finally added a section to the Developer Dashboard's site profile that shows the list of the plugins and themes (for websites that agreed to it, of course). We spotted a bug in the logic that determines plugins' activity status, making it look as if all the plugins on the site are deactivated. This release fixes the issue.

Auto-Updates UI Integration

WordPress 5.5 introduced a new UI to easily allow website admins to control whether a plugin or theme should be auto-updated:

This release extends the integration also to allow admins to control auto-updates for your paid products by following this recommended from core's team.

Additional bug fixes

  • Fixed a bug in the add-ons actions dropdown.
  • We introduced a new deactivate_on_activation filter to allow you to disable the free (or paid) plugin/theme's automatic deactivation when activating the paid (or free) version while the other version is still active.

Version Contributors

Official release notes:

Choose a tag to compare

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.


  • 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

Official release notes:

Choose a tag to compare

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:

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.


  • 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:

Choose a tag to compare

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: