define('DISALLOW_FILE_EDIT', true); Wordpress Plugins – unFocus Projects – Kevin Newman and Ken Newman

Scripts n Styles Update 3.1

Scripts n Styles received a major update today. The two big features added are LESS.js support and Dynamic Shortcodes! The “Global” Settings page now has a LESS editor with syntax highlighting (via CodeMirror) and on-the-fly compiling so you can see how it’ll be outputted on the theme-side. The per-page meta-box has gained a new tab in which you can create one-off shortcodes which can contain arbitrary HTML content.

Scripts n Styles is a free OpenSource GPL project that you can fork and contribute to on github! (You can also fork and contribute to CodeMirror and LESS.js)

As a Shortcode example: I placed the following html into the Shortcodes tab and gave it the name “tweet test”.

[code lang=”html”]
<a href="" data-via="WraithKenny" data-size="large" data-related="unFocusProjects" data-hashtags="ScriptsnStyles">Tweet</a>
<script>!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0];if(!d.getElementById(id)){js=d.createElement(s);;js.src="//";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs");</script>

I then use the shortcode [[sns_shortcode name=”tweet test”]] to display: [sns_shortcode name=”tweet test”]

Scripts n Styles update 2.0.1

Scripts n Styles is a tool to allow admins to add scripts and styles without editing template files, or worrying about authors overwriting the code.

Scripts n Styles is a tool to allow admins (and editors in single installs) to add scripts and styles without editing template files, or worrying about authors overwriting the code (code is stripped when an author updates since they don’t have permission to use unfiltered html).

Improvements in version 2.0.1:

The meta box has been improved to provide a tabbed interface for less clutter, and syntax highlight and formating is added using the open-source CodeMirror 2.1.

An option has been added to allow adding script to the head element in addition to the traditional bottom of the page spot.

An Options page (under Tools) has been added so you can add Script n Styles to the entire site, rather then just the individual posts and pages.

Some minor code improvements:

  • Better selection of post_types.
  • micro-optimization for storage of class names.
  • Defined a later priority for Scripts n Styles to print after other scripts and styles.
  • Better adherence to coding standards.
  • began contextual help (notes on capabilities).

Scripts n Styles

Introducing a new plugin for WordPress from unFocus Projects!

Ever need to add a CSS style or some code snippet to just one page or post in WordPress? We release an admin tool to do just that.

On the post edit screen of the admin, Scripts n Styles adds a meta box where you can add JavaScript, CSS or even add class names to the body tag or the post content wrapper (as long as the theme supports wp_head, wp_footer, body_class, and post_class functions and almost all do).

The plugin is available on Extend (and therefor your plugin admin screen 🙂 ). You can also fork it on Github. It’s licensed GPLv2. (current version 1.0.2)


Including Page Templates from a WordPress Plugin

Recently, It occurred to me while writing a plugin dealing with custom post types and taxonomies for WordPress that it’d be nice to have some custom templates to go along with it. I seemed onerous to ask the the user to add template tags to their theme to be able to display a better page then what WordPress displays by default. So I set out to make the plugin include the template pages from the plugin directory itself. The code below is derived directly from the WordPress source code, which means it’s GPL, so feel free to use it in your GPL licensed projects.

So the first thing I needed to figured out was what functions needed to be filtered to let me add the plugin directory to the locations that WordPress checks for. I eventually found the appropriate ones by reading the source code and asking in the #wordpress IRC chat (not #wordpress-dev, that’d be the wrong chat to ask this kind of question). “get_single_template()” and “get_taxonomy_template()” are the functions of interest and they in turn call “locate_template()” which is the function we need to rewrite.

[cc lang=”php”]
function locate_plugin_template($template_names, $load = false, $require_once = true )
if ( !is_array($template_names) )
return ”;

$located = ”;

$this_plugin_dir = WP_PLUGIN_DIR.’/’.str_replace( basename( __FILE__), “”, plugin_basename(__FILE__) );

foreach ( $template_names as $template_name ) {
if ( !$template_name )
if ( file_exists(STYLESHEETPATH . ‘/’ . $template_name)) {
$located = STYLESHEETPATH . ‘/’ . $template_name;
} else if ( file_exists(TEMPLATEPATH . ‘/’ . $template_name) ) {
$located = TEMPLATEPATH . ‘/’ . $template_name;
} else if ( file_exists( $this_plugin_dir . $template_name) ) {
$located = $this_plugin_dir . $template_name;

if ( $load && ” != $located )
load_template( $located, $require_once );

return $located;
[/cc](reference: ‘function locate_template‘)

The “locate_plugin_template()” function is a direct copy of “locate_template” function but I added the $this_plugin_dir variable (using code I found on the forums) and added a 3rd check to the foreach loop. (Some of the code here can be removed, for example the $load check with the load_template() call, as our code won’t be invoking it but I left it to better reflect the source.)

Next we have to filter the appropriate functions to call our new function.
[cc lang=”php”]
add_filter( ‘taxonomy_template’, ‘get_custom_taxonomy_template’ );
add_filter( ‘single_template’, ‘get_custom_single_template’ );

There’s not much in the original functions that need to be changed:

[cc lang=”php”]
function get_custom_taxonomy_template($template)
// Twenty Ten adds a ‘pretty’ link at the end of the excerpt. We don’t need it for the taxonomy.
remove_filter( ‘get_the_excerpt’, ‘twentyten_custom_excerpt_more’ );
remove_filter( ‘get_the_excerpt’, ‘twentyten_auto_excerpt_more’ );

$taxonomy = get_query_var(‘taxonomy’);

if ( ‘custom_taxonomy_name’ == $taxonomy ) {
$term = get_query_var(‘term’);

$templates = array();
if ( $taxonomy && $term )
$templates[] = “taxonomy-$taxonomy-$term.php”;
if ( $taxonomy )
$templates[] = “taxonomy-$taxonomy.php”;

$templates[] = “taxonomy.php”;
$template = locate_plugin_template($templates);
// return apply_filters(‘taxonomy_template’, $template);
return $template;
[/cc](reference ‘function get_taxonomy_template‘)

There’s some bonus remove_filter calls at the beginning and ‘locate_template’ is replace by ‘locate_plugin_template’. The only other thing is that we simply return the $template variable instead of using ‘apply_filters’ (I got errors when trying to apply the filter while running the filter filtering the filter :-/). There is also a check to see if we are working with our own taxonomy: The code in the if statement doesn’t really need to run again unless it’s one of our taxonomies, else it’ll just return the original $template.

The single template function filter is much the same:

[cc lang=”php”]
function get_custom_single_template($template)
global $wp_query;
$object = $wp_query->get_queried_object();

if ( ‘custom_post_type_name’ == $object->post_type ) {
$templates = array(‘single-‘ . $object->post_type . ‘.php’, ‘single.php’);
$template = locate_plugin_template($templates);
// return apply_filters(‘single_template’, $template);
return $template;
[/cc](reference ‘function get_single_template‘)

Now, this isn’t a perfect solution. For example, themes have much varying structures, so building a template that’s compatible with Twenty Ten wouldn’t necessarily be compatible with any other theme. If the theme isn’t compatible, it could be bad since you’ve interrupted the fallback that the theme provides in favor of yours. You should probably include a check to see if the current theme is the theme you are targeting. I suggest you use this code in a plugin that is basically a companion plugin for your own theme or framework. Additionally, you could offer template tag functions, shortcodes, and widgets as a more robust solution.

Correct User IP for WordPress comments on Mosso

Update #2: It looks like a couple of days after I posted this, the Mosso guys sent word on fresh clicks that the issue has been fixed on their end, rendering this plugin completely useless, days after I put it up. 🙂

I stumbled across a problem running WordPress on Mosso (Rackspace Clould) servers (which I’m now quite happily running on 🙂 ) in the Mosso Knowledge Base, where the ip address of the user is not properly recorded in comments when running in the Mosso cluster. The knowledge based linked to a fresh clicks article, but I wanted something a little easier to maintain than an inline hack. So I rolled a quick and dirty plugin, which seems to do the trick. Here is what it does:

[cc lang=’php’]
< ?php /* Plugin Name: unFocus.Mosso-User-IP Plugin URI: Description: A plugin to set REMOTE_ADDR on Mosso clusters to HTTP_X_CLUSTER_CLIENT_IP to fix tracking and comment posts, etc. Version: 1.0a Author: Kevin Newman Author URI: */ function unFocus_MossoUserIP() { $_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_CLUSTER_CLIENT_IP']; } add_action('init', 'unFocus_MossoUserIP'); ?>

That’s it! It just sets the regular REMOTE_ADDR value to the Mosso Server var HTTP_X_CLUSTER_CLIENT_IP. Pretty simple. 🙂 Update: I forgot to upload a zip archive.