Hot answers tagged

13

Instead of using wp_localize_script in that case, you can hook your js variables at wp_head, that way it would be available to all js files like: function my_js_variables(){ ?> <script type="text/javascript"> var ajaxurl = '<?php echo admin_url( "admin-ajax.php" ); ?>'; var ajaxnonce = '<?php echo wp_create_nonce( "...


9

You can simply put your init code within the constructor of the class. For example: class myWidget extends WP_Widget{ function myWidget(){ // Init code here } function widget( $args, $instance ) { // The widget code wp_enqueue_script(...); wp_enqueue_style(...); } // Over methods... } register_widget('...


6

You can export any data you want in the wp_head hook, as the answers above show. However, you should use json_encode to prepare the PHP data for exporting to JS instead of trying to embed raw values into JS literals: function my_js_variables(){ ?> <script> var ajaxurl = <?php echo json_encode( admin_url( "admin-ajax.php" ) ) ?>; ...


6

TL;DR There is no JavaScript API in the WordPress core and no one is planned, but actually, there is no need of it. Backend First of all let's say that, regarding the backend, some useful information can be fetched from already present JavaScript global variables (WordPress loves all global flavors). E.g. ajaxurl for the admin-ajax.php url to be used ...


5

Your code is PHP4 style. PHP4 styled code should not be used anymore. And just putting some functions inside a class construct is not OOP. If you want to write reusable code, separate your code. For example: class Widget_Setup { public $widget_class = ''; public $admin_styles = array(); public $admin_scripts = array(); public $...


5

This will be possible in WP 3.3: http://core.trac.wordpress.org/changeset/18480


5

wp_localize_script takes an array of data (in PHP) spits out a javascript. It's a way for you to add dynamic data for a specific script to the front end without having to hook into wp_head or wp_footer and echo it out yourself. More over, wp_localize_script outputs your data right above the script you enqueued. Hooking into wp_head or wp_footer won't do ...


5

W3 Total Cache has 4 locations to include the minified files. Since wp_localize_script() hooks into wp_head() (unless you specify in footer in your enqueue) you can use the before </body> minify location and your script will have access to the variables set. On some occasions this has failed for me so I just exclude the script from minify.


4

You should declare global $post; before attempting to access this variable, but to answer your question regarding when it is created, the 'wp' action hook is the safest bet. As such I'd suggest the following in your functions.php file as a simple solution function my_localize_post_id(){ global $post; wp_register_script( 'your_script'... /** other ...


4

Try this: $options = get_option( 'theme' ); wp_localize_script( 'flexslider', 'flex_vars', array ( 'flex_auto' => ($options['slide-auto']) ? 'true' : 'false', 'flex_animation' => $options['slide-animation'], 'flex_direction' => $options['slide-direction'] ) ); Assuming slide-auto is the option you made a boolean. This script isn't tested, ...


4

It's basically a unique id of the script you registered or enqueued before. Let's say we enqueued a two scripts with wp_enqueue_script(): wp_enqueue_script( 'my_script_1','/js/some_script.js' ); wp_enqueue_script( 'my_script_2','/js/some_other_script.js' ); Now you want to pass your $data to the script #2 with wp_localize_script(): wp_localize_script( ...


4

There has been quite a bit of development around the JSON REST API that is supposed to be merged into the 4.1 release. I believe it's officially going to be called the 'WP API'. You can begin using the codebase now and keep up with the latest developments here until it gets to core. Ryan McCue and team have fleshed out some pretty good documentation here.


4

As far as I know wp_localize_script doesn't escape data any more than is necessary to produce valid JSON, and everything is sent as a string. The function was originally designed to allow translating the strings used in your JS into other languages (hence the "localize" part of the function name). So if the data you're passing is coming from a user input or ...


3

In your code playerId is a string. So playerId.tracks can't work. So you can create a multidimensional array with wp_localize_script (WP 3.3+): $playlists = array( 'playlist150' => array( 'tracks'=> array('track1', 'track2') ), 'playlist257' => array( 'tracks'=> array('track3', 'track4') ) ); wp_localize_script( 'some_handle', 'allPlaylists'...


3

wp_localize_script() calls the method localize() on the global variable $wp_scripts. We can set this variable to an instance of a child class of WP_Scripts: class Filterable_Scripts extends WP_Scripts { function localize( $handle, $object_name, $l10n ) { $l10n = apply_filters( 'script_l10n', $l10n ); return parent::localize($handle, $...


3

The function wp_localize_script() is used to send variables to a script that has already been registered and enqueued. Do you have a js file that has been registered and enqueued and has the handle of 'ajax_URL'? If not, then that explains why it isn't working. Also, ajaxurl is already a js variable that is accessible via any scripts you enqueue, so I'm ...


3

You should be setting it to show in the footer with the register, so your code should look like this: wp_register_script( 'flowplayer_object', get_bloginfo( 'stylesheet_directory' ) . '/_/js/flowplayer/flowplayer-object-creator.js', array(), // these are your dependencies, if you need jQuery or something, it needs to go in that array false, /...


3

I ended up doing this. It works now !! Thanks @dot1 function itr_global_js_vars() { $ajax_url = 'var itrajaxobject = {"itrajaxurl":"'. admin_url( 'admin-ajax.php' ) .'", "itrajaxnonce":"'. wp_create_nonce( 'itr_ajax_nonce' ) .'"};'; echo "<script type='text/javascript'>\n"; echo "/* <![CDATA[ */\n"; echo $ajax_url; echo "\n/* ]]&...


3

While historically WP has been backā€“end centric, there had been declaration made for years now about moving towards heavy JS use. With backwards compatibility commitments in mind it is questionable that JS will achieve parity or take over PHP any time soon (in my opinion), but there had been some progress on it. The WordPress admin now ships with Backbone ...


3

To answer your statement: [...] there is no built-in Javascript API for Wordpress. Therefore developers who want to build on Ajax seem to come up all with their own solution which doesn't seem right to me. There is no "own solution" to be done. You can ease things by using ATP with ajax_template_part() by @G.M. or similar plugins and take a short cut, ...


3

wp_localize_script results in your data being printed to the page before your script tag via PHP, whether it be in wp_head or wp_footer, depending on where you've set your script to be output. Calling wp_localize_script from an AJAX handler won't do anything, you're returning data via JavaScript. What you can do is put any data you want to return from your ...


3

PHP wp_enqueue_scripts is a good time to localize the data. Make sure you target your script and create a name for the object as well as passing an array of data. In this case twitter_settings is the object that will be created and will hold all the data. twitter_settings.tweets_widget_id will ultimately hold your $tweet. add_action( 'wp_enqueue_scripts', ...


3

If you add the script inline you don't need to use wp_localize_script. All you have to do is directly print your inline script exactly as you need it dinamically. For example, in your template: <?php // The PHP code of the template here ?> <script> jQuery(document).ready(function($){ var s=1; $('button').on('click',function() { //...


2

Ok you can do it this way. function my_ajax_scripts() { $data = array( 'ajaxurl' => admin_url('admin-ajax.php') ); wp_enqueue_script( 'ajax_url', get_stylesheet_directory_uri() . '/my-custom-ajax.js' ); wp_localize_script( 'ajax_url', 'MyAjax', $data ); wp_enqueue_script( 'ajax_url_2', get_stylesheet_directory_uri() . '/my-custom-ajax-2....


2

One major principle of preventing security holes is "Escape late." That means that, ideally, esc_html() or esc_attr() should be used right when you echo or return the final HTML, not before. So, that's one thing that the example you gave gets wrong. As for the purpose of esc_html__(), as I understand it, is to prevent weird characters from translated ...


2

It really doesn't do much in that scenario. If you're going to leave that message as a string constant instead of something that is system or user generated, you're fine using one of the other translation functions: __() or _x(). esc_html__() is a little overkill for that particular line of code. Edit: The main reason for the esc_ functions is to protect ...


2

Sidestep the entire issue and just include fo_edit_script in the header of the page, rather than in the AJAX part. There's no need at all to do this. You might think that by only including it when its needed your optimising but your not, because it's having to load it every time you open an edit form. I'd go as far to say that what you're trying to do is ...


2

If lu_ban_object.method equals the string wrap, and you'd like to use that string to call jQuery's wrap() method, you'd use bracket notation : jQuery(function($) { $('.advert')[lu_ban_object.method]('<div>Hello World</div>'); });


2

There're easier ways than this. As @Wyck already stated that using globals is bad idea, here's a short explanation and how to: Why globals are bad: 1) Everyone can access them everywhere. First this sounds nice, but you can as well do the following: // Your code: default value global $foo; $foo = 'bar'; // User setting: global $foo; $foo = get_option( '...


2

You have to use the correct handle: wp_localize_script('page_data', 'glr_dt', $gallery_js_data_array); // Edit Your code is also wrong. What do you want to do in this line: 'maxPages' => '$gallery_max_load = $gallery->max_num_pages;' You are assigning a string to maxPages. I guess you want it that way (or similar): 'maxPages' => $gallery->...



Only top voted, non community-wiki answers of a minimum length are eligible