[wp-trac] [WordPress Trac] #19825: Bugs and modifications to localize script

[WordPress Trac]

#19825: Bugs and modifications to localize script
-------------------------+------------------------------
 Reporter:  ssmathias    |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |
-------------------------+------------------------------

Comment (by ssmathias):

 Replying to [comment:3 azaozz]:
 >
 > $wp_scripts->localize() accepts an associative array as argument, why
 would you pass an object? Further it has "dual functionality": that array
 can be multi-dimentional and html_entity_decode() is run only on the first
 level, leaving the second + levels untouched.
 I don't have a good reason why I would pass an object at this time, but I
 don't see a reason not to support it, and therefore believe it should be
 supported. As far as the "dual functionality", that portion is still being
 handled the same way, with it only encoding the first level and leaving
 the deeper levels untouched.

 > Don't see any advantages in storing the associative array(s) and
 json_encoding them at output (it actually used to do that at one point).
 This can only bring some collision problems when localize() is called more
 than once for the same script.
 There are a couple of reasons I would leave the data alone. The first is a
 philosophy my organization and I use, which is that data should be
 preserved and only changed for output when it is being output, unless
 there is good cause to change it in advance.

 The second reason is because it does take some processing time to convert
 the data into the JavaScript string, and ultimately that script may be
 removed. If that is the case, then we've wasted some processing time that
 could be avoided otherwise. I will grant it's a small amount in all but
 the most extreme cases, but it does exist.

 I don't see how we would have any more collision problems than already
 exist with the current functionality, in which you can also localize a
 script more than once. In one case, you'd have an array key overwritten
 with a new value, in another you'd have a JS variable overwritten with a
 new value. The same collision and resolution would occur, as I see it.

 > Also direct hacking into the $wp_scripts object is not supported as the
 internals can change in newer versions.

 Exactly why I feel that such an interface as this would be necessary.
 Right now, for me to achieve the goals for one of our clients (which is to
 reduce ALL JS requests to a single request), I would have to dig down into
 the "data" key in the WP_Dependency object, copy that string, and manually
 replace it into the underlying WP_Dependency object on my concatenated
 script file. This actually forces me to tie more closely to the current
 implementation than I would like.

 By being able to get the localized object off of one script through a
 supported method, then localize my concatenated script with
 wp_localize_script, I can avoid needing to know the underlying
 implementation of that localization functionality.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/19825#comment:4>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software