wp_localize_script( string $handle, string $object_name, array $l10n ): bool
Localize a script.
Contents
Description
Works only if the script has already been registered.
Accepts an associative array $l10n and creates a JavaScript object:
"$object_name" = {
key: value,
key: value,
...
}See also
Parameters
-
$handlestring Required -
Script handle the data will be attached to.
-
$object_namestring Required -
Name for the JavaScript object. Passed directly, so it should be qualified JS variable.
Example:'/[a-zA-Z0-9_]+/'. -
$l10narray Required -
The data itself. The data can be either a single or multi-dimensional array.
Return
bool True if the script was successfully localized, false otherwise.
More Information
This function localizes a registered script with data for a JavaScript variable.
This lets you offer properly localized translations of any strings used in your script. This is necessary because WordPress currently only offers a localization API in PHP, not directly in JavaScript (but see ticket #20491).
Though localization is the primary use, it was often used to pass generic data from PHP to JavaScript, because it was originally the only official way to do that. wp_add_inline_script() was introduced in WordPress Version 4.5, and is now the best practice for that use case. `wp_localize_script() ` should only be used when you actually want to localize strings.
$object_name is the name of the variable which will contain the data. Note that this should be unique to both the script and to the plugin or theme. Thus, the value here should be properly prefixed with the slug or another unique value, to prevent conflicts. However, as this is a JavaScript object name, it cannot contain dashes. Use underscores or camelCasing.
$l10n is the data itself. The data can be either a single- or multi- (as of 3.3) dimensional array. Like json_encode(), the data will be a JavaScript object if the array is an associate array (a map), otherwise the array will be a JavaScript array.
IMPORTANT! wp_localize_script() MUST be called after the script has been registered using wp_register_script() or wp_enqueue_script() .
Furthermore, the actual output of the JavaScript <script> a tag containing your localization variable occurs at the time that the enqueued script is printed (output/included on the page). This has some significant repercussions if you enqueue your script as you should using the appropriate actions (wp_enqueue_scripts and admin_enqueue_scripts), but wish to localize later using data that is not available at enqueue time.
In this case, consider enqueueing your script with the in_footer argument set to true, to delay the printing of your script include until much later in the page build (ie: wp_enqueue_script( $slug, $URL, $deps, $ver, true ); ).
The last chance to localize your script would then be on the 'wp_print_footer_scripts' hook.
Source
File: wp-includes/functions.wp-scripts.php.
View all references
function wp_localize_script( $handle, $object_name, $l10n ) {
global $wp_scripts;
if ( ! ( $wp_scripts instanceof WP_Scripts ) ) {
_wp_scripts_maybe_doing_it_wrong( __FUNCTION__, $handle );
return false;
}
return $wp_scripts->localize( $handle, $object_name, $l10n );
}
Changelog
| Version | Description |
|---|---|
| 2.2.0 | Introduced. |
User Contributed Notes
You must log in before being able to contribute a note or feedback.
to send ajax request from theme files we can use wp_localize_script to globally declare our javascript variables.
in our js file we can use any of the globally declared variable
frontend_ajax_object.ajaxurl, frontend_ajax_object.data_var_1, frontend_ajax_object.data_var_1.Top ↑
Feedback
Note: This comment is incorrect as of WordPress 4.5.
wp_localize_script()should not be used to pass arbitrary data to JavaScript, see: https://developer.wordpress.org/reference/functions/wp_localize_script/#comment-3213. — By Andrew Ozz —`wp_localize_script()` is often used to pass generic data from PHP to JavaScript, because it was originally the only official way to do that.
wp_add_inline_script() was introduced in WP v4.5, and is now the best practice for that use case. `wp_localize_script()` should only be used when you actually want to localize strings.
Example
You can access the variables in JavaScript as follows:
Note: The data in the resulting JavaScript call will be passed as text (see ticket #25280). If you are trying to pass integers you will need to call the JavaScript
parseInt()function.Top ↑
Feedback
Note: The examples in this comment are incorrect as of WordPress 4.5.
wp_localize_script()should not be used to pass arbitrary data to JavaScript, see: https://developer.wordpress.org/reference/functions/wp_localize_script/#comment-3213. — By Andrew Ozz —Note, calling this function multiple times in the a single session with the same object name will overwrite previous values,
If you need to have multiple data sets associated with the same script (handle), then you need to rename your object,
Top ↑
Feedback
Or remove the original code and replace with the code you need:
global $wp_scripts; $data = $wp_scripts->get_data( 'enqueued-script', 'data' ); if ( empty( $data ) ) { wp_localize_script( 'enqueued-script', 'obj', $localized_data ); } else { if ( ! is_array( $data ) ) { $data = json_decode( str_replace( 'var obj = ', '', substr( $data, 0, -1 ) ), true ); } foreach ( $data as $key => $value ) { $localized_data[ $key ] = $value; } $wp_scripts->add_data( 'enqueued-script', 'data', '' ); wp_localize_script( 'enqueued-script', 'obj', $localized_data ); }— By Gabriel Reguly —Feedback: It would suggest for clarification:
Top ↑
Feedback
Actually an script tag with inline content is printed, but it gets printed before the script it belongs to, instead of after in the sense of attached, and the script will override it, if it contains for readability (say) the english-version of the object. — I suggest a warning on the behaviour of the function wp_localize_script. — — By PeterF —
I do have more feedback: the example for $object_name, ‘/[a-zA-Z0-9_]+/’, does not lead to a qualified Javascript name, not even to a valid Javascript identifier, as it allows to begin with a digit. (It is not example, but a (not right) rule). May I suggest to drop the regex, and put perhaps a plain example name qualified by plugin prefix. Also I notice that the first line of the description (with the word added) should be the second line or dropped at all, such that the first line reads what the function does, and the restriction added is repeated later-on in different more precise words under IMPORTANT. Thank you for reading so far. — By PeterF —