Scripts To Footer vs Show Theme in Footer

This small plugin moves scripts to the footer. Note that this only works if you have plugins and a theme that utilizes wp_enqueue_scripts correctly. You can disable the plugin on specific pages and posts directly via the post/page edit screen metabox. You can disable the plugin on specific archive pages (blog page, search page, post type and taxonomy archives) via the settings page. Everything Broken? Try placing jQuery back into the header via Settings > Scripts to Footer, “Keep jQuery in the Header” checkbox. If that doesn’t work, refer to the walkthrough below for using the stf_exclude_scripts filter for the script that is causing the issue. Check out the documentation on GitHub or some quick walkthroughs below. Keeping specific Scripts in the Header As of version 0.6 you can now keep specific scripts in the header. Note: this will print any scripts they depend on as well (if you want to keep jquery-effects-core in the header, you’ll also get jQuery in the header, so no need to add both). Specifically for jQuery, see the settings page option, as it is a common request we’ve built it into the settings. For any other scripts, use this filter: add_filter( 'stf_exclude_scripts', 'jdn_header_scripts', 10, 1 ); function jdn_header_scripts( $scripts ) { $scripts[] = 'backbone'; // Replace 'backbone' with the script slug return $scripts; } You will need the correct script slug, which is used when the script is registered, and the script will only be printed into the header if it’s enqueued. Check out the scripts that come registered out-of-the-box with WordPress. Note: As of version 0.6.3, conditional tags will work with the stf_exclude_scripts filter. Custom Post Type Support If you’re comfortable with code you can use the scripts_to_footer_post_types filter to change the post types this applies to (it only applies to pages and posts by default). For example, if you have a custom post type called “project” you could add support for this metabox via the post type filter like this: function stf_add_cpt_support( $post_types ) { $post_types[] = 'project'; return $post_types; } add_filter( 'scripts_to_footer_post_types', 'stf_add_cpt_support' ); Excluding Pages/Posts/Templates Via Filter You can either use the checkbox option to disable the plugin’s action on a specific page/post, or you can utilize a filter. The filter also passes the post/page id, if there is one (archive templates don’t have ids!). For example, for the “page” post type: function stf_exclude_my_page( $exclude_page, $post_id ) { if ( is_front_page() ) { $exclude_page = 'on'; // this turns on the "exclude" option } return $exclude_page; } add_filter( 'stf_page', 'stf_exclude_my_page' ); Replace stf_page with stf_post for posts, or the slug of your custom post type. For instance, a post type called “project” can be filtered with stf_project. More Documentation See the plugin’s wiki. Development / Contributing View this plugin on GitHub. Support Please feel free to open a Github Issue to report conflicts or goto the WP.org support forum. If there is something wrong with Scripts-to-Footer, we’ll update it. However, if it’s a another plugin or theme we can only contact the developer with the issue to attempt to resolve it.

This plugin displays the active theme name, version and parent theme name in the Admin Footer on the right. Parent theme is only shown when a child theme is active. We created this plugin because we manage a large number of blogs with different themes. When updating themes we always have to go and look which theme is active and which is the parent theme to prevent problems with the site layout. We always like to be sure before updating the active theme, but others non active theme should always be up to date. Info is only shown to logged in Administrators and Editors. Easy. Handy. And it saves us a lot of time. We think it will save a lot of time of everybody that manages blogs with different themes. Show Theme in Footer in your Language! This first release is avaliable in English and Spanish. In the languages folder we have included the necessary files to translate this plugin. If you would like the plugin in your language and you’re good at translating, please drop us a line at Contact us. Further Reading You can access the description of the plugin in Spanish at: Show Theme in Footer. Contact For further information please send us an email. Translating WordPress Plugins The steps involved in translating a plugin are: Run a tool over the code to produce a POT file (Portable Object Template), simply a list of all localizable text. Our plugins allready havae this POT file in the /languages/ folder. Use a plain text editor or a special localization tool to generate a translation for each piece of text. This produces a PO file (Portable Object). The only difference between a POT and PO file is that the PO file contains translations. Compile the PO file to produce a MO file (Machine Object), which can then be used in the theme or plugin. In order to translate a plugin you will need a special software tool like poEdit, which is a cross-platform graphical tool that is available for Windows, Linux, and Mac OS X. The naming of your PO and MO files is very important and must match the desired locale. The naming convention is: language_COUNTRY.po and plugins have an additional naming convention whereby the plugin name is added to the filename: pluginname-fr_FR.po That is, the plugin name name must be the language code followed by an underscore, followed by a code for the country (in uppercase). If the encoding of the file is not UTF-8 then the encoding must be specified. For example: en_US – US English en_UK – UK English es_ES – Spanish from Spain fr_FR – French from France zh_CN – Simplified Chinese A list of language codes can be found here, and country codes can be found here. A full list of encoding names can also be found at IANA.