PHP 8 Compatibility, Clone Resolution Out of Beta, Revamped Opt-In and License Activation, and Tons More!

All of the features and updates included in version 2.5.0-RC.1 (a release candidate) are now part of the SDK. If you are still on 2.4.x (or below), please take the time to review the previous release notes to familiarize yourself with the expected updates.

Here are 2.5.0-RC.1 highlights:

• Clone Resolution Mechanism
• Deactivation Feedback Form Snoozing
• User Assets Ownership Switch Resolution
• Fix of HTTP 404 Not Found (AKA ‘No Updates’)
• Fault Tolerance to Background Connectivity Issues

PHP 8 Compatibility

The new SDK version resolves all reported PHP 8 incompatibility issues and warnings 🐘

Clone Resolution Is Out of Beta

The Safe Mode & Clone Resolution mechanism introduced in 2.5.0-RC.1 is officially out of beta. In addition to the bug fixed during the beta period:

• The mechanism now properly supports multilingual websites.
• We improved the clone identification logic to cover more cases.
• The auto resolution was also significantly improved, reducing the number of manual interactions.

We’ve also introduced a new FS__RESOLVE_CLONE_AS flag, which allows you to programmatically guide the mechanism for resolving clones upon site replication. The flag can easily be added to a site’s wp-config.php (or functions.php) with one of the following values:

// A temporary duplication for the purpose of testing, staging, or development.
define( 'FS__RESOLVE_CLONE_AS', 'temporary_duplicate' );

// The new site is replacing the old one — this will migrate the license activation to the new site to resolve the clone.
define( 'FS__RESOLVE_CLONE_AS', 'new_home' );

// The cloned site is a new and different one — this will automatically activate the license on the new site to resolve the clone.
define( 'FS__RESOLVE_CLONE_AS', 'long_term_duplicate' );

Opt-In v.2.0

Following tons of feedback, we are excited to introduce the next generation of our opt-in screen 🎊

In addition to the slicker UI:

• The opt-in copy underwent a significant overhaul to better communicate the purpose of the opt-in screen as well as what can be expected when opting in.
• The permissions list was reviewed thoroughly to ensure it covers exactly what’s shared when opting in.
• We switched the framing of the copy from “How it helps developers” to “How it helps you” — “you” being the user installing the product. This helps to emphasize the user benefits of opting in.
• New tooltips were added to most permissions, adding more context to how sharing the info benefits users.
• To minimize confusion among users unaware of Freemius, we removed the Freemius logo from the opt-in screen. We updated the permissions micro-message to clarify that opting in means sharing the info with the product’s team. Basically, positioning Freemius as the opt-in facilitator and data processor.

‘Anonymous’ License Activation

Like the opt-in, the license activation also went through a similar UI and framing refresh. What’s even more exciting is that licenses can now be activated with a minimal data footprint. This means only sharing the essentials needed for Freemius’s license & updates delivery engine:

• Homepage URL
• Product version
• SDK version
• Whether the product is active (or uninstalled)

That’s it!

So anyone sensitive about privacy can easily expand the permissions list and toggle off the new Diagnostic Info permission. This skips the sharing of WordPress & PHP versions, and site language & title.

Thanks, Chris Wiegman, for providing your feedback on it!

User IP Sharing — No More!

After our CEO Vova Feldman participated in a live QA about Freemius, a concern was raised about sharing user IPs.

For context, the IP was used to identify users’ geolocation to help developers recognize which languages & regions their plugin/theme should be translated and tailored to. It can also be used for security purposes to flag suspicious activity and prevent impersonation.

Even though it was only shared with user consent upon opting in, we have re-evaluated the need for this data point and decided to remove it altogether:

https://github.com/Freemius/wordpress-sdk/pull/580/files

Along with the user IP removal, we’ve also stopped sharing the nickname of the opting in user — this was used as a placeholder when the user had an empty first and last name.

Thanks, Sean D., for bringing it to our attention!

Skip … Is Only for Skipping

When we launched Freemius in 2015, the WordPress.org repository didn’t have the active installs growth chart (which was recently back in the news after its removal). At the time, plugin and theme developers were “thirsty” to understand how efforts to improve their products impacted adoption. To solve this problem and give developers an accurate picture of their product usage, skipping the Freemius opt-in also sent an anonymous ping, which increased the product’s “skips” counter. Along with the Deactivation Feedback Form and some heuristics, we could offer an estimate of the product’s audience size.

Long story short: over the years, we realized the skips counter is far from accurate, unreliable, and prone to errors, which is why we’ve removed it from the new dashboard. Combined with the fact that some didn't like this behavior, the Skip button is just for skipping the opt-in now. That's it.

Improved Copy for Email Verification

The connection between the SDK and the Freemius API is secured with public/private keys and we manage a single entity per email address. If a person with the same email address has already opted in on another website, we have to make sure they are not impersonating by confirming the ownership of their address before sharing the keys with the website.

Following feedback (thanks, David McCan), we realized the email copy was confusing. We therefore revised the copy to clarify the purpose of the confirmation:

Granular Opt-Out Permissions

To make the opt-in permissions more flexible and allow users to pick and choose what they want to share, the team has introduced a brand new permissions management layer for free and paid products.

Clicking the Opt Out action link now opens a new dialog box where users can selectively choose which of the permissions they want to opt out from or keep sharing:

The granular permissions support new states that were not supported before. For example, a user can stay subscribed to receive email updates from the product team while opting out from sharing diagnostic info about their WordPress environment.

And here’s how it looks for paid products:

The new permissions layer comes with complementary events you can consume through a webhook:

install.extensions.opt_in

Occurs whenever a user opts in for sharing a website’s plugins & themes list after previously opting out from it.

install.extensions.opt_out

Occurs whenever a user opts out from sharing a website’s plugins & themes list after previously sharing it.

install.user.opt_in

Occurs whenever a user opts in for sharing their basic profile info after previously opting out from it.

install.user.opt_out

Occurs whenever a user opts out from sharing their basic profile info after previously sharing it.

You can find the complete events list here:

https://freemius.com/help/documentation/marketing-automation/events-webhooks/

Important:

• For consistency, starting from Jan 1, 2023, the events install.connected and install.disconnected will be renamed to install.site.opt_in and install.site.opt_out (correspondingly). So, if you “listen” to any of these events through a custom webhook, make sure to update the webhook to support the new event names before.
• If you are using Freemius’s MailChimp Integration, make sure to update your rules by unsubscribing a user from your lists when install.user.opt_out occurs, and optionally resubscribing them on install.user.opt_in.

New Actions to Further Customize the Opt-In Screen

We’ve introduced a new set of actions to enable more advanced (yet still structured) customization of the opt-in screen:

connect/before

For adding text or visual elements before/above the opt-in container.

connect/after

For adding text or visual elements after/below the opt-in container.

connect/before_message

For adding text or visual elements before/above the opt-in message header (within the opt-in container).

connect/after_message

For adding text or visual elements after/below the opt-in message (within the opt-in container).

connect/before_actions

For adding text or visual elements before/above the opt-in action buttons.

connect/after_actions

For adding text or visual elements after/below the opt-in action buttons.

You can find the complete documentation of the opt-in screen customization options here:

https://freemius.com/help/documentation/wordpress-sdk/opt-in-message/

WP AJAX Querystring Parameters — De-touched 👋

Since version 2.0.1, the SDK comes with advanced support for multi-site networks. As part of the implementation, we needed a way to identify if an admin notice needed to be dismissed from the network admin or site-level admin.

Unfortunately, due to WordPress limitations, there’s no way to programmatically know if an AJAX request was initiated from the network or sub-site admin. So, we came up with a simple jQuery snippet that intercepts WP Admin AJAX requests before they are triggered. This enriches them with a querystring flag based on the admin context so the backend code will have the proper context. We chose this approach because it was the easiest and most efficient code-wise.

Long story short, this implementation raised concerns as it gave the impression that the SDK was monitoring all AJAX requests. While it’s obviously not the case, we all know how impressions matter. So, I’m happy to share that we are no longer intercepting admin AJAX requests. The querystring flag is now only added to AJAX requests triggered by the SDK:

https://github.com/Freemius/wordpress-sdk/pull/578/files

Thanks, Amber C., for continually calling us out on this!

New Staging & Testing Domains Identification

The SDK now automatically identifies staging & testing sites hosted on WPMU DEV, InstaWP, and Vendasta. This identification allows for license activation without deducting from the production activations quota. You can check the complete list of supported sites here:

https://freemius.com/help/documentation/selling-with-freemius/license-utilization/

Updated the Delete Link to Disconnect

To reduce confusion, the previously titled Delete link shown in the Account page is now titled Disconnect:

In addition, the link now shows a confirmation dialog box explaining exactly what the disconnection means:

Call for Translators

Following the opt-in and license activation screen updates, we’ve introduced new strings and updated some of the previous ones to make the messaging clearer. We need your help in translating the strings:

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

In addition, we now have a formal German translation team and will officially add the locale once it covers at least 50% of the strings.

Object Cache Issues — Resolved

After an in-depth investigation, the development team discovered that the SDK’s caching layer was redundant. Removing it resolved all sorts of caching issues for sites using Object Cache.

Notable Bug Fix

• The SDK now gracefully handles the case when a multi-site network turns to a regular site (previously, it was throwing PHP errors).
• The User Dashboard link in the affiliate application form was updated to the new dashboard.
• If SECURE_AUTH_KEY is missing, the SDK will no longer throw a PHP error and will work around the missing constant.
• The Beta program participation checkbox is also visible for sites with an activated white-labeled license.

New SDK Release Strategy

We are moving away from mega releases and towards micro releases. It will allow for releasing new versions in much shorter cycles so that developers can enjoy the bug and compatibility fixes and new features in confidence, without the concern of using the develop branch.

What’s Next?

Once the new SDK gets adopted, we'll most likely discover more edge cases related to the clone resolution that we'll need to fix.

Except for those, we want to address several more (small) user-facing concerns in the next release.

In addition, we'd like to prioritize reevaluating the SDK's storage architecture. We received concerns about the size of the fs_option record, so we are finally going to deep-dive to understand its impact. According to our findings, we’ll possibly need to adjust the storage design to reduce the resource consumption as much as possible.

Finally, we are well aware of the need for a lite SDK, and it's on our list. Once we finish handling the two concerns mentioned above, we'll get back to planning and designing what a ‘lite’ and more modular SDK could look like.