Tag Info

Hot answers tagged

9

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( ...


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

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.


5

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... } ...


4

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" ) ) ?>; ...


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.


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

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

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', ...


3

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 ...


3

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, ...


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 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 ...


3

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


3

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( ...


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, ...


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

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

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

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() . ...


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' => ...


2

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, ...


1

the_content filter is (most likely) running long after you scripts were output. You need to either: Run localize logic earlier. Enqueue scripts for footer, using respective wp_enqueue_script() argument.


1

I tested that code like this: wp_enqueue_script('jquery'); wp_localize_script( 'jquery', 'MS_Ajax', array( 'ajaxurl' => admin_url( 'admin-ajax.php' ), 'nextNonce' => wp_create_nonce( 'myajax-next-nonce' )) ); And it works but throws a Notice. It should be hooked to wp_enqueue_scripts like: function my_enqueue_scripts() { ...


1

Try making the original script a dependency <?php wp_enqueue_script( $handle, $src, 'original_script_handle'); ?>


1

You should use wp_localize_script() after enqueuing your JS file that calls the countdown method. I'm assuming you stored the date in an option called date_name like January 1, 2015 13:30:00. In your case, you are storing it as an array with month, day, year, and time in the correct format, so you should convert it to the January 1, 2015 13:30:00 format. ...



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