This dog’s head has been deep in code in preparation of what I see as a next big step for SPLOTs… (update as this post lingered in draft, the plugin is out and about, please test, please. Please).
Usually I toss a lot of technical discoveries into a full post; but as an active reader of Tom Woodward (He Who Formerly Called Himself a Non-Programmer, put that in a footnote!) I like his idea of small code “patterns” that maybe are worth blogging on their own.
So here is one small thing I think might be useful. All of the SPLOTs have an entry form where site visitors can enter tags; to take advantage of the built-in WordPress auto suggest for a tag form field, one needs to have a small bit of code in a jQuery script file that is loaded with the page that builds the form.
Previously I was able to hack the write path it needs because I knew that the page it was called for was http://splotsitename.whatever/write. But I have folded a new feature into it where you can now desginate any page as your writing form.
Then I found a thing I did not know you could do from a site with the lovely name of Code Chewing; a way to send a variable value from the PHP/Wordpress side of a function / theme template into a JavaScript file that is enqueued for that page.
It’s like handing data across a gap.
It’s a thing WordPress thing called wp_localize_script. Or from the codex put in place for being able to send localized translations of strings:
Though localization is the primary use, it can be used to make any data available to your script that you can normally only get from the server side of WordPress.
And I needed the same thing the Code Chewing demo offered, a way to send the main site web address of a WordPress site. For TRU Writer, I was able to send this variable to a script file:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
// custom jquery for the uploader on the form wp_register_script( 'jquery.writer' , get_stylesheet_directory_uri() . '/js/jquery.writer.js', array( 'suggest') , '1.8', TRUE ); // add a local variable for the site's home url wp_localize_script( jquery.writer, 'writerObject', array( 'siteUrl' => esc_url(home_url()) ) ); wp_enqueue_script( 'jquery.writer' ); |
This means my JavaScript can now access the value of siteURL:
|
1 |
jQuery('#wTags').suggest( writerObject.siteURL + "/wp-admin/admin-ajax.php?action=ajax-tag-search&tax=post_tag", {multiple:true, multipleSep: ","}); |
This is used so that a form field named wTags can autocomplete tags as typed into.
Knowing this provides a solution to this specific need but also opens the door for other ideas where I need WordPress to hand over some data to an enqueue JavaScript file.
Is anyone with me at this point? Just checking. See if it works for you at the demo for SPLOTWriter plugin – there are tags that start with do... (and while there, maybe try testing it out fully.
Featured Image:
Handoff flickr photo by blmurch shared under a Creative Commons (BY) license
Localize is so very handy for the js interactions. I am less impressed with the WP documentation on it. I’m impressed with all the work you’re doing to make the plugin versions. It’s not an easy path.
For the record, I’m still not much of a programmer but I have raised the bar for what a programmer is based on what I know now. Maybe someday.
I have a site which uses several Gravity Forms embedded in various modals. The modal itself isn’t attached to the post, so getting the post ID or user ID automatically is tough. Being able to pass the WP variables (thanks to help from Tom because yes, the documentation was…something…) saved my skin.