If you plan to do a lot of WP development you should bookmark this page: http://codex.wordpress.org/Conditional_Tags The other answer works but the conditional relies upon your page slug (myurl.com/this-is-the-slug) never changing. A more reliable method (IMO), and one that fits this case, would be to use the is_page_template(‘example-template.php’) conditional check instead.
There is a function called wp_script_is( $handle, $list ). $list can be one of: ‘registered’ — was registered through wp_register_script() ‘queue’ — was enqueued through wp_enqueue_script() ‘done’ — has been printed ‘to_do’ — will be printed Ditto all that for wp_style_is().
I want to use @import instead so I can override styles more easily Simply. Don’t. Do. That. You simply jump into the same hook and then deregister/dequeue the styles/scripts and throw in your custom ones. function PREFIX_remove_scripts() { wp_dequeue_style( ‘screen’ ); wp_deregister_style( ‘screen’ ); wp_dequeue_script( ‘site’ ); wp_deregister_script( ‘site’ ); // Now register your styles … Read more
Well, you have wp_localize_script(), but that’s only for passing data. Otherwise, you can do this: function print_my_inline_script() { if ( wp_script_is( ‘some-script-handle’, ‘done’ ) ) { ?> <script type=”text/javascript”> // js code goes here </script> <?php } } add_action( ‘wp_footer’, ‘print_my_inline_script’ ); The idea is that you shouldn’t rely on your inline script being printed … Read more
The wp_register_script() Codex page literally says: A safe way of registering javascripts in WordPress for later use with wp_enqueue_script(). This means, if you want to register your scripts, but not directly load them in your pages, you can register the files once, and then load them when you need them. For example: You have a … Read more