Description #Description

There are 3 different use-cases: 1) New plugin installation right with Freemius: 1.1 _activate_plugin_event_hook() will be executed first 1.2 Since $this->_storage->is_plugin_new_install is not set, and $this->_storage->plugin_last_version is not set, $this->_storage->is_plugin_new_install will be set to TRUE. 1.3 When _plugins_loaded() will be executed, $this->_storage->is_plugin_new_install will be already set to TRUE.

2) Plugin update, didn’t have Freemius before, and now have the SDK: 2.1 _activate_plugin_event_hook() will not be executed, because the activation hook do NOT fires on updates since WP 3.1. 2.2 When _plugins_loaded() will be executed, $this->_storage->is_plugin_new_install will be empty, therefore, it will be set to FALSE.

3) Plugin update, had Freemius in prev version as well: 3.1 _version_updates_handler() will be executed 1st, since FS was installed before, $this->_storage->plugin_last_version will NOT be empty, therefore, $this->_storage->is_plugin_new_install will be set to FALSE. 3.2 When _plugins_loaded() will be executed, $this->_storage->is_plugin_new_install is already set, therefore, it will not be modified.

Use-case #3 is backward compatible, #3.1 will be executed since 1.0.9.

NOTE: The only fallback of this mechanism is if an admin updates a plugin based on use-case #2, and then, the next immediate PageView is the plugin’s main settings page, it will not show the opt-in right away. The reason it will happen is because Freemius execution will be turned off till the plugin is fully loaded at least once (till $this->_storage->was_plugin_loaded is TRUE).