Add `wp_localize_script` to the file, not inline

If it’s dynamic data, it needs to be generated each request. If you tried to write it to a file, it would take longer, and you’d have to generate a different file for each request so that requests wouldn’t step on each other.
If it’s not dynamic data, why isn’t it in a file already?

Perhaps you should use an AJAX request for the data instead of your current method.

You could reference a .php file as a script’s src attribute and have the PHP generate an appropriate .js file data stream. It’ll save you from needing to generate different static files. But it still involves the overhead of requesting an external file and having PHP interpret its content. And the .php file probably needs to reload the WP environment so it can access WP resources, which adds even more overhead. If all the data is really needed on the page, you’re much better off keeping it as inline data.

@joyously The data is not dynamic. I mean, i filled it’s in a Dashboard, saved and that’s it.

If it’s not dynamic data, why isn’t it in a file already?

Because I wrote earlier, what method i’ve used to add the data – wp_localize_script
To have an access to the data I used this method and created myOptions object to access data.
What can I use instead?

• This reply was modified 4 years, 7 months ago by evgenyp.

You can use the wp_localize_script to pass the smaller data of the admin URL, and get the rest of the options using AJAX. Or create your own REST route.
Or use the options to generate in PHP what is needed, instead of doing it in JS.

@joyously could you explain, please, how can I get this.
Probably, you have useful links.
My Custom Post type contains 52 fields
And I have 20+ posts that use that CPT. So I have a big volume of data.
And I don’t understand what should I do in php and javascript file.
Sorry, i really confused.
Appreciate your tips.

Well, you haven’t actually said what your plugin is doing. Is this for the editor? Is it user input on the front end? Is the data already in the database? Are you trying to put the 52 fields in the right place in the custom post output on the front end? Are you using the 52 fields to calculate something, or are they simply data to display?

You could learn a lot from looking at the code for the plugin Advanced Custom Fields and the many add-ons it has. This has all been figured out already, so you could use the code or just use the plugin if you aren’t trying to distribute your own.

Basically, do as much as you can on the server, in PHP, because there is no client interference. Then the part that has to be interactive is the part that is in JS.

I use 52 fields in the right place in the custom post output on the front end. All those 20 posts use custom post types.
And I use wp_localize_script( 'my-scripts', 'myOptions', $context['options'] ); for the only reason – have an access through the object myOptions.

So data is in DB, it’s static.
I didn’t to mention that I use Timber, don’t know if it’s matter.

// add fields from options page
$context['options'] = get_fields( 'options' );

// add site options to combined js file
wp_localize_script( 'my-scripts', 'myOptions', $context['options'] );