FOR INTERNAL USE ONLY
The process that happens when a plugin is updated, especially the conversion of pre-existing options to SLPlus options / options_nojs serialized JSON objects.
In older releases , including some vestiges that still existing in 2209.X versions, options were stored in a WordPress option_name that match the plugin name. Such as option_name ‘slp-power’ for the power add on. Each add on had its own set of options.
When Smart Options were introduced into the SLP architecture there were two options that stored “all settings”. csl-slplus-options (aka “options”) stores settings that were not being localized and sent to JavaScript. csl-slplus-options_nojs (aka “options_nojs”) are the settings that are not localized. (In theory… both of these will be replaced with a single monolithic store in csl-slplus-options eventually and specific settings retrieved from JavaScript via a REST call).
The idea was to eventually (soon?) convert all separate plugin-specific option settings like option_name = ‘slp-power’ into a standard csl-slplus-options string. Below is the flowchart that describes how that conversion happens.
The Activation Class
Each add on has a file ./include/class.activation.php (another legacy vestige) that includes the Activation class. Such as SLPPower_Activation.
To get an option converted to a “Smart Option” and thus be stored in the main SLP options or options_nojs serialized JSON object you need to extended the $SmartOptions property in the plugins activation class.
The keys listed in the array should match pre-existing option names for the plugin.
The Smart Option should set use_in_javascript setting (try not to use this at all) set to true to store in options or false to store in options_nojs.