How to properly use fw_backend_options_render in ajax?

[danyj]

OK this is becoming ridiculous and I refuse to believe that this is the way this should be done.
Please help me out here.

I have in theme/options file topmenu.php that contains $options array of 20 options for top menu.

Than I have topmenu current options serialized and saved to a file , just an example

fw_options%5Bmenupreset%5D=style1&f.......

Id rather use JSON but according to this way of doing things it needs to be serialized https://github.com/ThemeFuse/Unyson/blob/bdc4f3ab1ed59e2c0b1ded227eb093cd1f556b4a/framework/static/js/fw.js#L933

Now in order for me to re-render my saved options , I need to :

run ajax to get options default array   by looking in to topmenu.php ( why? ) 
run ajax to get my saved serialized preset
run ajax  to  get the values  with  fw_backend_options_get_values ( why? ) 
run ajax to render and return html with  fw_backend_options_render

is there any way to shorten this madness?

can I use just max 2 ajax calls ?

run ajax to get my preset 
run ajax to rerender  

[danyj]

So much to think about , but the thing is that I must have this , imagine coding 5 presets for notifications that have 25 options 10 presets for icons boxes 30 options 10 presets for special headings 20 options 10 presets for buttons 15 options

if I dont do this right , all those must use multi picker and you know how that will endup

[danyj]

side one , does

fw_get_variables_from_file

for ok with

ftpext

[danyj]

WORKS brother! :+1:

o after_setup_theme run function that reads preset file via

fw_get_variables_from_file

and gets default presets array , than creates the new presets option on generate preset , update that option with new preset and re-render

I set

define('FS_METHOD', 'ftpext')

and tested , everything looks fine

if

get_filesystem_method

is returning direct , I show a button that will let you add new preset to the preset file and in DB , this way you can add-on presets to that file while you work .

if you have any concerns please let me know.

and again as always , thank you for this 24/7 brainstorming with me . I would have ran in lots of trouble if you did not pointed out the FTP issue.

[ghost]

side one , does

fw_get_variables_from_file

for ok with

ftpext

fw_get_variables_from_file has nothing to do with WP_Filesystem. It uses include/require, not fopen/fclose

on after_setup_theme

On every page load?

---

I prefer the solution used in builder templates

• There are predefined templates in theme file
• Theme updates can change/improve/add predefined templates
• Predefined templates can't be deleted (no delete button)
• User templates are saved in db and are shown first in templates list

So again

$presets = array_merge(
    $user_presets_from_db,
    $theme_predefined_presets_from_file
);

[danyj]

On every page load?

no , on first time , there is check for the option , if not there than it runs it

function _thz_load_thz_presets(){
    $thz_options_presets_option = 'thz_options_presets:'. fw()->theme->manifest->get_id();
    if ( !get_option( $thz_options_presets_option )  ) {

        $get_thz_options_presets = fw_get_variables_from_file(THZFW_PRESETS.'/thz-options-presets.php',array('thz_options_presets' => array()));
        add_option($thz_options_presets_option,$get_thz_options_presets);

    }

}

add_action('after_setup_theme', '_thz_load_thz_presets');

I see what you mean with merge now , it makes sense , why add predefined ones to DB at all , just add user ones and than merge array from predefined and array from user DB.

I will probably go that route and dont have to create that option on after_setup_theme but create it when user saves the first time.

But in both cases this is exact way it works

There are predefined templates in theme file Theme updates can change/improve/add predefined templates Predefined templates can't be deleted (no delete button) User templates are saved in db and are shown first in templates list

[danyj]

About DB data limits , you think 100KB is an issue , or what was the limit you were mentioning in other posts. I know there was something .

You see way I did it now is 1 option with multi array ,

example

$thz_options_templates['topmenutemplates']['style1'] = array(
        'label'     => 'Style 1',
        'canremove' => false,
        'data'      => '{style1data}'
);

$thz_options_templates['topmenutemplates']['style2'] = array(
        'label'     => 'Style 2',
        'canremove' => false,
        'data'      => '{style2data}'
);

$thz_options_templates['iconboxtemplates']['style1'] = array(
        'label'     => 'Style 1',
        'canremove' => false,
        'data'      => '{style1data}'
);

$thz_options_templates['iconboxtemplates']['style2'] = array(
        'label'     => 'Style 2',
        'canremove' => false,
        'data'      => '{style2data}'
);

so not to hit limits should I leave it like that or rather make an option for each group like

thz_options_templates_topmenutemplates

thz_options_templates_iconboxtemplates

[ghost]

I am pretty sure it will be fine with one option.

We hit limits when we have a lot of shortcodes with a lot of options (with multi-picker, you know that multipicker value is quite big). Then in that option, the same builder data is stored in 3 variants: original json, corrected json, wordpress shortcode notation.

[danyj]

ok thnx bud!