jquery-ui-datepicker localization feature (wp_localize_jquery_ui_datepicker)

How would you suggest this be addressed then? Especially scripts within shortcodes. How would WP determine what scripts are within shortcodes? Or just blindly register all the time no matter what?

Disclaimer: What follows is my personal opinion. I’m in no way representing any official interpretation on behalf of the WordPress organization.

From the perspective of WP development guidelines, if someone were to load any jquery module anywhere besides the proscribed enqueue actions, they are considered to be Doing It Wrong?, so I really cannot see WP core devs considering this a “bug”.

I’m not suggesting what you say is incorrect. I’ve no doubt modules are loaded from wp_head, and even within shortcode handlers. Even if it’s a very common practice, that does not mean WP development guidelines should be weakened in order to conform. There’s several reasons everything is supposed to be enqueued through a common action. Allowing other practices defeats many of these.

Coders are free to load whatever modules they want where ever they want. If they choose to not follow accepted guidelines, the onus is on them to also deal with associated issues like registering localization.

Thanks for your thoughts.
Well, in my opinion wp_add_inline_script should work like actions and filters do: you register your extension and whether the script is inserted into html, extensions are also inserted, no matter where it will happen, in head or in footer. Correct me if I’m wrong, but most user-interaction scripts (like datepicker) could be loaded after the page body and are not required in head.

For now I manually call wp_localize_jquery_ui_datepicker in shortcode after I enqueue plugin script, which depends on jquery datepicker script.

When you first mentioned inline scripts, I took that to mean simply echoing out something inside of <script> tags. Using wp_add_inline_script() is a different animal even though the final result is not much different. What is different is wp_add_inline_script() is tied into the WP_Scripts class that handles script registration, enqueuing, dependencies, etc. To use wp_add_inline_script(), the script needs to first be enqueued, which establishes dependencies. This very different than hooking into “wp_head” and using scripts outside of the WP_Scripts enqueuing system.

If you’ve properly enqueued an inline script and specified the dependencies within the appropriate enqueue scripts actions, then subsequent localizations should work correctly. And yes, many scripts do not need to be loaded in head. There’s a boolean parameter in wp_enqueue_script() to indicate that the script should be loaded in the footer.

Given all that, I don’t think it matters much when the actual script output occurs as long as it’s after all the registration and enqueuing is finished. If you’re not using one of the enqueuing actions to localize your script, you’re responsible for ensuring it occurs late enough, especially if footer enqueuing is used.

If you’ve done all of that and the localization fails, then perhaps there is a bug. In order to have a bug addressed, you’d need to provide all pertinent information and code necessary for anyone to reliably reproduce the bug. I’ve run into some dependency glitches myself. I’ve chosen to just work around the issue instead of trying to resolve the bug. It sounds like you’re in a similar situation.

All you said is right. I like this wordpress scripts system and never insert scripts in any other way.
The only thing is that I speak about not my personal inline script, it is WordPress’s. This localization function wp_localize_jquery_ui_datepicker is wordpress’s internal, and is added by wordpress in default-filters.php like this:

add_action( ‘wp_enqueue_scripts’, ‘wp_localize_jquery_ui_datepicker’, 1000 );
add_action( ‘admin_enqueue_scripts’, ‘wp_localize_jquery_ui_datepicker’, 1000 );

So wordpress will translate datepicker automatically if it will be enqueued in one of these two actions.
Or if I add wp_localize_jquery_ui_datepicker as action to other later actions like wp_head or wp_footer.
Or if I manually call wp_localize_jquery_ui_datepicker in the right place.
But I don’t feel comfortable messing with stuff intended to be working silently by itself, that’s why I decided to ask here.

More data!
I found that wp_add_inline_script(script_handle, code) will register inline code even if the script handle is not enqueued yet! If script is enqueued later then inline code is added to it. Thats the behaviour I have expected!
But wp_localize_jquery_ui_datepicker checks manualy if datepicker has been enqueued!
if ( ! wp_script_is( ‘jquery-ui-datepicker’, ‘enqueued’ ) ) {
return;
}

I don’t know why it checks. This check is indirectly included in wordpress’s scripts system. And removing that check here will fix everything.

I would assume the datepicker check is just to avoid needlessly localizing data if it’s not going to be used. A small gain for sure, but having spent much time weeding out redundant meta tags due to sloppy coding by plugin authors, I appreciate the effort even though it’s complicating things for you.

I wonder if the inline registration is really happening before being enqueued. You may have called these in your code in the wrong order, but do your callbacks execute in that order? It’s easy to predict order if the hooks are added with different priorities, but what of hooks all added with the same priority, in particular the default 10? The word is the order is alphabetical by callback name, but it’s unofficial, so subject to future change. Don’t rely on it.

Even so, you may be right. I don’t have a good handle on the inner workings of WP_Scripts, but since it needs to resolve dependencies, it may be that as long as enqueuing happens, it doesn’t matter when. In any case, an interesting discovery!

You’re right to be reluctant to mess with internal workings. I’d say though, that as long as you’re not altering core code directly and not using procedural functions that start with an _underscore, it’s probably fair game. That’s not to say there might not be integration issues with other themes or plugins. How far you go depends on if you are simply hacking a particular site for yourself or a client, or if you are writing a theme or plugin that needs to play well with other unknown entities. It’s more of a judgment call than yes or no.

I wonder if the inline registration is really happening before being enqueued. You may have called these in your code in the wrong order, but do your callbacks execute in that order?

Yes, inline registration is called from wp_enqueue_scripts action, that enqueue check prevents it from registering, so that means datepicker is not enqueued. I enqueue datepicker in shortcode which is far more later than wp_enqueue_scripts. If I remove ‘return’ inside wp_localize_jquery_ui_datepicker, wp_add_inline_script is getting called, still far earlier than datepicker in my shortcode, and registered localization script is getting into html after datepicker script in the middle of html.