Better init for addons.

[freemius]

Better init for addons.

[vovafeldman]

Thanks for the note Daniel. We don't hook to plugins_loaded intentionally. Why? Freemius leverages register_uninstall_hook for reporting abount 'uninstall' event (for users who opted-in). Connecting to register_uninstall_hook on plugins_loaded is too late since the uninstall hook is invoked before.

Another note, Freemius already handles the error messaging when the parent plugin is missing, so you can remove that part from your Freemius powered add-ons.

[danieliser]

@vovafeldman - About to test it so maybe I am missing the error message handling you mentioned for addons. But even in that case you are assuming that Freemius is loaded, as the addons doesn't include a copy of the SDK. So if the parent isn;t active then the addon can't have access to the SDK no?

My method requires including the activation class with every addon, but no die messages. I simply add an admin notification to the top of every page saying Addon X requires Popup Maker, please install|activate it now. Where the install link will immediately install the free plugiin and the activate will activate it.

I will look into the uninstall hook issue. What all needs to be available at that hook? I am assuming that you don't really need the plugin & addons initialized there, just freemius sdk to send the uninstall notice? In which case you could still use plugins_loaded for initializing plugins/addons but load the SDK immediately so it will always be available as soon as possible. Then the register_uninstall_hook would not be affected.

Maybe I missed something. Just installed your test plugin & addons to experiment with.

[vovafeldman]

Yes and no... :) We built the SDK to support the use-case of a core plugin without Freemius, which can work with a Freemius powered add-on. So:

1. If the parent plugin is not active but has Freemius folder, the add-on will load the SDK from the parent's folder.
2. Another option is to include the SDK in the add-on.

With regards to the register_uninstall_hook, yes, it's for the uninstall notice. In any case, since you can't assure that your add-on's file will be included after the parent plugin's file, if you put the SDK init code-blocks simply as part of the file, when the add-on's SDK is initiated, Freemius will add an error message that the parent plugin is not active.

Here's the problematic flow:

• WordPress includes the add-on first (and it can happen, it's not some esoteric use-case)
• Freemius SDK must be initiated, otherwise register_uninstall_hook callback won't be executed on deletion
• As part of the init process, Freemius checks if the parent's plugin Freemius instance exist
• Since the plugin was not yet included, Freemius instance was not yet generated for the plugin; therefore the add-on's instance will throw a corresponding message

It's a tricky case, but hope it makes things clear.

[danieliser]

@vovafeldman I see this all the time with Popup Maker. The official solution is to use the plugins_loaded hook for everything that isn't required before that point which excludes register_uninstall_hook and others like it.

For those things I can fire my plugins init if needed but generally I don't need everything.

I think the following would solve both problems.

Init the SDK inline so it is initialized immediately so that it can be used by hooks.

Run the plugin classes init function on plugins_loaded. I don't see any reason that they have to be married in that respect. Then all the addons can load the freemius SDK if its not loaded already, all will be registered properly. You can also have the SDK wait until plugins_loaded before checking for the parent plugin.

In reality what I would like to see is all of this rolled into the SDK so that the addon doesn't have to worry about it. That is what we should aim to do here.

What if we made a function in the SDK that does the foreach on active plugins and returns true or false. Then the developer simply does 1 short if check to load it.

Hope that makes since.

[danieliser]

PS I personally feel that those types of checks are really part of the product offering you seem to be going for, putting them in your code rather than the your users just makes for a better product. Let the addon code focus on addon functionality.