Posts tagged ‘plugin’

Took a look at @anywhere a little while ago. With my experience working with the Facebook javascript methods, it was rather trivial to incorporate the new javascript functionality from Twitter into Simple Twitter Connect, so that was exactly what I did.

Simple Twitter Connect 0.7 now automatically enables your site to run the new @anywhere code. With zero extra configuration steps.

All the example javascript code they give on the @anywhere documentation site will work immediately.

I even added an example plugin (STC-Linkify) to demonstrate how it works. Activate that plugin and it will automatically link any Twitter usernames on your page to Twitter. So when I type @ottodestruct or @otto42, they’re automatically linked. Neat, eh?

I’ll be adding several more @anywhere plugins to the package soon, but those will be in the next update. If you want them in advance, then you can see the trunk version of the plugin and pick and choose which you want. I’ve already added the Follow Button widget to there, so you can go get it now if you like. I’m already using it here in my sidebar. :)

Shortlink:


I’m working on a Simple Google Connect for the future. But for now, here’s a simple Buzz Button using the functionality they announced today.

sgc-buzz.php

<?php
/*
Plugin Name: SGC - Buzz Button  
Plugin URI: http://ottopress.com/wordpress-plugins/simple-google-connect
Description: Adds a Google Buzz button to your content.
Author: Otto
Version: 0.1
Author URI: http://ottodestruct.com
License: GPL2

    Copyright 2010  Samuel Wood  (email : otto@ottodestruct.com)

    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License version 2, 
    as published by the Free Software Foundation. 
    
    You may NOT assume that you can use any other version of the GPL.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.
    
    The license for this software can likely be found here: 

http://www.gnu.org/licenses/gpl-2.0.html

*/

wp_enqueue_script( 'google-buzz-button', 'http://www.google.com/buzz/api/button.js', array(), '1', true );

/**
 * Simple GB button
 *
 * @param int $post_id An optional post ID.
 */
function get_buzz_button($id = 0) {
	$url = get_permalink($id);
	$out = '<a title="Post on Google Buzz" class="google-buzz-button" href="http://www.google.com/buzz/post" data-button-style="normal-count" data-url="';
	$out .= $url;
	$out .= '"></a>';
	return $out;
}

function buzz_button($source = '', $id = 0) {
	echo get_buzz_button($id);
}

/**
 * Simple buzz button as a shortcode
 *
 * Example use: buzz id="123"
 */
function buzz_button_shortcode($atts) {
	extract(shortcode_atts(array(
		'id' => 0,
	), $atts));
	return get_buzz_button($id);
}

add_shortcode('buzz', 'buzz_button_shortcode');

function buzz_button_automatic($content) {
	$button = get_buzz_button();
	$content = $content . $button;
	return $content;
}
add_filter('the_content', 'buzz_button_automatic', 30);
Shortlink:

Over on my Simple Facebook Connect page, there’s lots of comments from users with problems. Having answered these for a while now, via there and via email, I’ve come to the conclusion that people don’t search for answers to their problems.

The “How to fix the Email Domain” problem is answered on that one page no less than 6 times, for example. Almost all the rest of the problems given come from the “wrong connect URL setup” issue.

So if you don’t want to do support all the time, I think you have to make your plugin smarter. Take the most common issues you see and make the plugin auto-detect the problems. That’s what I’ve done with SFC version 0.16, for example.

Error Messages

Error messages now show up when the user configured something wrong on Facebook.

The plugin now can detect these two major causes of problems and will display an error message. It also provides a link to the right place on Facebook to go and correct these problems. It can’t actually fix the problems directly (though that is possible… small steps), but I hope this will eliminate the need for me to continually have to answer the same questions over and over again.

So my tip for the day for plugin programmers: For robustness, make your plugin check for commonplace issues. And the issues that you think will be commonplace may not be the ones you expect, so figure on having to add more and more checks every time.

Shortlink:

Too often I see themes missing the absolute minimum requirements to make the theme actually work properly. So I figured I’d make a list of things that ALL WordPress themes need to have in them, every time. These are WordPress theme-specific things. I’m not including obvious stuff like HTML and such.

Note: These are my opinions. You may not agree with every one of these. My opinion in that case is that you’re wrong, so there’s little point in arguing with me unless you have a rock-solid reason for disagreeing with me. In other words, I’m not trying to start a flame war, nor am I interested in one. This is just a checklist that I hope theme authors will start following more often. It would make me happy if all themes had these. :)

  • wp_head() in the HEAD section.
  • wp_footer() just before the /BODY tag. (So many themes forget this simple little thing…)
  • language_attributes() in the opening HTML tag.
  • body_class() in the BODY tag.
  • post_class() in whatever surrounds each individual post (probably a DIV).
  • Use of get_header(), get_sidebar, and get_footer inside every appropriate page template.
  • The Loop inside every page template (exception: very Custom Page Templates).
  • Proper use of widgets on the sidebars (dynamic_sidebar, register_sidebar, etc).
  • A special image.php template. Image attachments can have their own template and make theme’s have built in nice gallery-like support. You should make a special one of these to fit your layout.
  • Comments must use wp_list_comments(). Preferably without using a customized callback. But if you must make a callback, be sure to support threading properly! This is tricky without also having an end-callback. And you should use a List to do it (unordered or ordered, it doesn’t really matter). If you’re using DIVs, you’re doing it wrong.
  • The Comments Reply form should have id=”commentform”. If you change this, you’re breaking plugins.
  • Similarly, you need to include do_action(‘comment_form’, $post->ID); on your comment form too.
  • A couple of useful Custom Page templates. Like a no-sidebar one, or one that has a different number of columns. Just generic ones to let your user have a few built in options.
  • New to 2.9: Thumbnail support. Come on, this is cool stuff, every theme needs to have it.
  • New to 3.0: Forget doing your own comment form at all. Just make the call to comment_form(). Then adjust it through styling or filters or what have you. Plugin authors will love you for doing this.
  • New to 3.0: Nav-menu support. It’s cool. Your users will love you for supporting it.
  • New to 3.0: add_theme_support( ‘automatic-feed-links’ ); in the function.php. This will make it do the feed links in the head for you, automagically.

This list is by no means complete. It’s just off the top of my head for now. But honestly, too many themes don’t have even the basic ones, and I’d like to see that fixed. If you’re a theme author, help everybody out, let’s make a list of standards and adhere to them. Users hate editing their themes to support their favorite plugins, and with standards like these, we could make it so that they didn’t have to.

Shortlink:

Originally published here: http://ottodestruct.com/blog/2010/dont-include-wp-load-please/

Note: There is a followup post to this one, which details an even better way than the two given below: http://ottopress.com/2010/passing-parameters-from-php-to-javascripts-in-plugins/

Time for Otto’s general griping: WordPress plugin programming edition.

Here’s a practice I see in plugins far too often:

  1. Plugin.php file adds something like this to the wp_head:
    <script src='http://example.com/wp-content/plugins/my-plugin/script.js.php'>
  2. Script.js.php has code like the following:
    <?php
    include "../../../wp-load.php";
    ?>
    ... javascript code ...
    

The reason for this sort of thing is that there’s some option or code or something that the javascript needs from the database or from WordPress or whatever. This PHP file is, basically, generating the javascript on the fly.

Usually, the case for this turns out to be something minor. The code needs the value from an option, or some flag to turn it on or off. Or whatever.

Problem is that finding wp-load.php can be a bit of a chore. I’ve seen extreme efforts to find and load that file in plugins before, including searching for it, examining the directory structure to make decent guesses, etc. This sort of thing has existed even before wp-load.php came around, with people trying to load wp-config.php themselves and such.

But the real problem is simpler: This is always the wrong way to do it.
Continue reading ‘Don’t include wp-load, please.’ »

Shortlink: