I would never recommend NetSol for any sort of service of any kind, but damn if they can’t make a funny parody.

Google has a pretty neat interactive Doodle for Thanksgiving…

• Pirate: http://g.co/doodle/7gmtj5
• Wizard: http://g.co/doodle/y4rs2x
• Beanie hat on bicycle: http://g.co/doodle/enz2bt
• Disco Roller Skater: http://g.co/doodle/zskwej
• Astronaut: http://g.co/doodle/my24pw

There’s more, but I haven’t found them all yet. To find them, just get the right combination of shoes, hat, and feathers and poof, it transforms.

This tweet got me to thinking about the myriad uses of technology used for rather simple things.

Weather Station Example

For example, the weather. The National Weather Service has set up climate observation stations throughout the US, at places like airports, on top of tall buildings, alongside freeways, random places in the countryside, even on ships and buoys in the ocean. These monitor the temperature, humidity, and a bunch of other things of that nature. Sometimes they’re integrated into the overall system, like at an airport tower, sometimes they’re just self contained boxes mounted somewhere with power, like on a freeway sign or beside the road. Anyway, these boxes record this information and generally use radio transmitters to send updates back to some centralized location in each region. Usually a local university, TV station, NWS local offices, etc.

This information is then sent on to the next stop via various methods. As the technology evolved, old methods like phone lines got replaced with the internet, or on other more secure lines. They call this overall system The Gateway, and it has its own special protocols and methodologies along with it as well. Anyway, the data is sent back to the NWS’s central server center somewhere. Probably in DC, although they likely have multiple redundancy in various other locations. This information is naturally combined with all the other information from all over the world, so that a complete up-to-date system of meteorlogical data of the entire world can be maintained.

Thousands of other organizations read from this data via various protocols of their own. For example, The Weather Channel gets a lot of their information from this large, distributed, database via some kind of real time feed. They even re-serve the data themselves using various formats, such as the XOAP system.

That XOAP system is interesting because it’s a pretty good feed of weather related data for various regions. I use it myself, indirectly. On my iPhone, for example, I have the Typophone Weather application, which uses the 3G network (which is itself a highly connected system of radio towers using multi-spectrum packet switching technologies), to connect to the internet (this big system of pipes which is in reality not all that well put together but nevertheless works because of incredible fault tolerance in its various protocols), in order to query that XOAP system (which uses XML and SOAP standards for its interface).

All this happens in order to display the current temperature on my iPhone’s lock screen, while I sit here on a couch, not four feet from a friggin’ window.

The future is awesome.

A while back, the personal genetic testing company 23andme offered a special sale. They discounted their normal price from $500 to $99 for one day only. Naturally, I jumped on it.

Just got my results back. Nothing particularly surprising here, but it is neat.

• My blood type is A (A/O). I knew this, good to see it backed up by genetics.
• I have an elevated risk for Type I and II diabetes (no news here, my sister is diabetic).
• Apparently, I can’t taste “bitter”. This does explain why I love Brussels Sprouts.
• I’m lactose intolerant. I was pretty sure of this already.
• I have a natural resistance to norovirus (stomach flu). Didn’t know that.
• I am a carrier for Cystic Fibrosis. I don’t have it, but it’s possible that my children could.
• I am a slow caffeine metabolizer. It says that drinking coffee increases my heart attack risk (duh), but I’m not sure what this really means. Caffeine typically doesn’t do a thing to me, at least not immediately. I go through a fair amount of it on a regular basis.
• Paternal Haplogroup: I1*, Maternal Haplogroup: H1. This basically makes my ancestry 100% European. Very vanilla there. However, this does conflict with my known ancestry slightly, in that it says I don’t have any Native American ancestors (within 5 generations). But then again, I don’t have a whole lot of reliable information on that branch of the family tree.

There’s a ton more information (apparently I’d respond really well to Interferon Beta Therapy, whatever the hell that is), and I haven’t gone through it all yet.

One thing I did note is that they do allow you to download the raw data, which is pretty cool. However when I looked at it, I noticed that it’s not a complete record of your DNA, just a sampling. Basically it’s like 500,000 markers of it instead of the full 3 billion or whatever. Clearly you don’t need the complete sequence to draw useful information out of it.

Still, kinda neat that this is within the reach of the average person.

Since people have been emailing me and asking for it…

WordPress Plugin: Simple Twitter Connect

It’s similar in concept to the Simple Facebook Connect plugin. In fact, it rips off quite a lot of the same code. But instead of Facebook, this integrates your WordPress site better with Twitter.

Now, there’s a lot of Twitter plugins out there already. And this plugin by no means competes with them (yet). This plugin can’t, for example, send a post to Twitter (yet). Nor can it pull posts from Twitter to display on your own site (yet).

What it does is to provide the framework for a more complete Twitter integration. Right now it can do:

• Login via Twitter
• Comment via Twitter

Not much, really. But it has the backend code necessary to make it easier to connect your site to a Twitter Application, and to make plugins surrounding it that won’t interfere with each other. That’s the same basic reason for the Simple Facebook Connect plugin.

So yes, eventually this plugin will send and receive stuff from Twitter. But for now, it lets you allow users to Login and/or to have users Comment using their Twitter credentials.

Expect frequent updates.

Edit: This post has moved to here: http://ottopress.com/2010/dont-include-wp-load-please/. Take your comments there.

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.

Why this is wrong

1. You don’t have the first clue where wp-load.php actually is. Both the plugin directory and the wp-content directory can be moved around in the installation. ALL the WordPress files could be moved about in this manner, are you going to search around for them?
2. You’ve instantly doubled the load on that server. WordPress and the PHP processing of it all now have to get loaded twice for every page load. Once to produce the page, and then again to produce your generated javascript.
3. You’re generating javascript on the fly. That’s simply crap for caching and speed and such.

The right way? Well, there’s two options.

Right Way the First

Generate your options separately, put them in using wp_print_scripts.

Examine this pseudo-code:

add_action('wp_print_scripts','myscript');
function myscript() {
?>
<script type="text/javascript">
  var plugin_option= <?php echo json_encode(get_option('plugin_option')); ?>;
</script>
<?php
}
wp_enqueue_script('myscript','...myscript.js',...);

Basically, the plugin option value is inserted directly into the page. The myscript.js file that loads shortly afterwards can use this value however it likes.

Why this is better:

1. No searching for wp-load.php.
2. The javascript is static, only your options are variable. No added load on the site.
3. Static scripts mean you get great speed from caching.

Sidenote: Note the use of json_encode? You should always use this when producing javascript variables from PHP variables. It handles quoting and escaping and everything for you. It can even turn PHP arrays into javascript arrays nicely! Handy for storing all your options in one place.

What if you have a ton of plugin options though? What if you really WANT to generate that javascript on-the-fly?

Right Way the Second

Generate the javascript from a call to WordPress itself, not to a separate file.

Examine this pseudo-code:

add_filter('query_vars','plugin_add_trigger');
function plugin_add_trigger($vars) {
    $vars[] = 'plugin_trigger';
    return $vars;
}

add_action('template_redirect', 'plugin_trigger_check');
function plugin_trigger_check() {
	if(intval(get_query_var('plugin_trigger')) == 1) {
	?>
function javascript_code() {
...
}
<?php
	exit;
	}
}

That code does something a little clever. Basically it’s adding a new query variable to be used as the “trigger”. When the trigger gets pulled, a bunch of javascript is generated, then the code *exits*, stopping WordPress from proceeding any further.

So, with that code in a plugin, a call to http://example.com/?plugin_trigger=1 will now produce your javascript code. This is running entirely within the content of a WordPress call, so you get all the WP functions and database access with which you can generate your code as well.

Thus, you can happily put your

<script src="http://example.com/?plugin_trigger=1">

code into the page and it’ll load up that “file” just fine.

Why this is better:

1. No searching for load.php
2. … Well, okay, there is no other reason. The load problem still exists, and your caching issues still exist. You’re programmatically generating code here, after all. It’s not a particularly good practice to do. Still, sometimes this is easier and faster to develop, even if it’s never actually “necessary”.

Also see that while I’m using the number 1 there as the value I’m checking for, that value can be anything you like. If you want to be a smartass about it and have all sorts of different things that could be generated, you can do them all with that one trigger. It’s still a generally bad idea because of the added load, but hey, maybe you have a legitimate reason. I’ve seen one or two valid reasons to do this before.

Wrap up

Also note all of the above also applies to “generating” CSS code. It’s just as unnecessary. Usually more so.

So please, stop including wp-load. It’s just wrong. Let WordPress load itself, and make your plugin do the output it needs to produce in the right places.

Note: This post has been moved to here. Please leave comments there instead.

The majority of the email I get from users of the Simple Facebook Connect plugin is questions regarding how to setup their Facebook Application. It’s really not that hard to do, but the plethora of options can seem somewhat intimidating. So here’s the basics of what you need to do.

After creating your application, you’ll need to visit the Apps section in the Facebook Developer Home area. Here you’ll find your application, and the all critical “Edit Settings” link.

Firstly, never give out your Application Secret. If you give this out by accident, then use the Reset Secret Key link to get a new one.

Anyway, from here, you want to go into the settings. The settings area is divided into six main sections, but most of the settings are irrelevant. See, you’re building a “Connect” application, not a “Canvas” one. So most of these are meaningless for you. The following ones are what you actually care about:

Obviously, you want the name of your Application to make sense. I suggest using the same name as your website. You can even use your domain name here if you like. Just be aware that this name is what the Fans of your site will see in their Applications area.

The Basic Information section is important as well, fill it in as you see fit. I also recommend uploading good icons and/or logos for your site. Gives it that finished look.

Contact Information is obviously important as well, but don’t worry about all those extra URLs. They really apply more to Canvas apps. Of course, if you want to make special pages on your site for them and provide the URLs here, feel free.

The Authentication Settings page is surprisingly important. Those top two boxes need to be unchecked for a Facebook Connect application. Why? Because when they are unchecked, your Application becomes an “External Website” as far as Facebook is concerned. If you have either them checked, then your app’s Canvas section becomes active and you might have users trying to add it to their profiles and such, resulting in broken pages and a general bad user experience.

The Connect Settings page is probably the most important one. These settings must be filled in and they must be absolutely accurate. Specifically, the URLs must be the URLs that are actually used by your site. Capitalization matters. The leading “www” or lack of one matters. Whatever the URL your site is in the browser is what you MUST put into these fields. Anything less and your site will not work.

The Advanced Settings screen contains these three fields which you need to set in the same way I did. The email domain should be your own domain, obviously. This field must be filled in for you to get real user emails on your Connected site. Without this, you only get proxied emails through Facebook.

Finally, after you have saved those settings, take the time to go back to the main application screen and click the “Edit Application Profile” link. You’ll be taken here, where you can set up the “look” of your application page on Facebook. This includes what tabs are visible, the stuff in the Info section, etc. You can add extra Applications tabs to this page and generally customize all sorts of stuff. None of that affects your site, but it does affect how the App Page looks in Facebook. The more polished it is, the more likely people will “Fan” your Application. And Fans get updates from when you publish posts to the Wall. Great way to drive traffic to your content.

Hope this helps! Mainly, I hope this reduces the number of questions I get about this process. Enjoy SFC!

I saw this morning that Jesse Stay had created a rather neat little chicklet for his FBFoundations plugin. I thought it was a clever idea, so naturally I stole it and added it to Simple Facebook Connect as well.

Of course, just copying an idea is no fun. So I had to improve upon it a bit for my version.

I ended up not using any of Jesse’s code, but I did (mostly) keep the format of his chicklet output the same, so as to try to be compatible with it for styling rules and such.

Usage

The SFC Chicklet works in one of a few ways:

• First, it’s a widget if you just want to stick it in a sidebar or something. That’s easy.
• On the other hand, if you want to integrate it into your theme, then all you have to do is to add a call to sfc_chicklet(); anywhere you like.

Configuration (Styling)

Now, unlike Jesse’s FBFoundations plugin, Simple Facebook Connect is all about simplicity. So I removed all the configuration options that he used (widths, colors, etc) and made them styleable instead.

The SFC Chicklet has a default set of styles that it puts right into the HTML itself. However, these can be easily overridden by your own styles in your theme. The thing to notice is that all the styles I use refer to classes only, not referencing the tags. So, if you re-style and use the tags as well, then your styles win the specificity war, and will take precedence.

Thus, if you want to change the background color of the main box, you can do this:

div.fanBoxChicklet {
background-color:blue;
}

Simple. The “div” makes it take precedence. Anybody familiar with simple CSS should be able to easily style it the way they like.

On the other hand, if you’re a super-themer and want to disable the built-in styles entirely, add this to your theme’s functions.php file:

global $sfc_chicklet_no_style;
$sfc_chicklet_no_style = true;

Extra

And, of course, this new plugin supports both the Application and the Fan Page methods, for those of you who have your webpage hooked to a Fan Page. This is similar to the new support for Fan Pages in the SFC Publish and SFC Fan Box plugins.

If you’re a real power user, you might want to display a chicklet for more than one page or application. Well, we’ve got you covered, just call sfc_chicklet(“ID-NUMBER”), where ID-NUMBER is the ID of your application or page. Remember, this needs to be a string, not an integer.

Internals

Internally, the plugin uses the Facebook PHP library to get the necessary data from Facebook, so there’s no need to have any odd javascript or ajax requests to make the system work. Because of the use of this Facebook code, PHP 5 is required to use this plugin.

However, the Facebook code includes a JSON library (if you don’t have one already loading), which means that if you activate this plugin, it’s quite probable that the whole SFC system will run on WordPress 2.8, even if it wouldn’t before. Of course, since 2.9 was just released, this is not as big of a deal, really.

The plugin also uses the WordPress Transients API as a caching mechanism, so that it only asks Facebook for the fan count a maximum of once per hour. The Transients API was introduced in 2.8, and so the plugin should still work okay if you haven’t upgraded to 2.9 yet.

And if you can come up with any other good Facebook plugin ideas, let me know. SFC has proven to be an easy platform for building simple Facebook plugins on top of, so they can probably be produced pretty quickly and easily.

Installation

If you haven’t installed SFC yet, then this chicklet is part of the package. Just download it and install from here:
http://wordpress.org/extend/plugins/simple-facebook-connect/

Alternatively, in a WordPress installation, just go to the “Plugins->Add New” area and search for “Simple Facebook Connect”. You can install the package directly from there.

If you already are using SFC 0.8, then you only need the new file. You can download it separately here:
http://plugins.svn.wordpress.org/simple-facebook-connect/trunk/sfc-chicklet.php

Just drop it into your /wp-content/plugins/simple-facebook-connect directory, then activate it in the Plugins panel.

Heard of geotagged tweets yet? Not surprised, a lot of my friends seem to have not caught on to it, so I’m writing this in a possibly futile attempt to get them to try it out.

How to add your location to your tweets

1. Turn on Geotagging. To do this, go to your Twitter settings page. Down under the “Location” section is an option to enable geotagging. Turn it on.

Twitter Settings

2. Get a Twitter client that supports Geotagging. These are generally mobile applications. Tweetie 2 for the iPhone added support for it in 2.1. Several other clients support it as well. Find one.

3. Turn it on in your client. How you do this depends on the client, but it can usually be enabled on a per-tweet basis.

Here’s an example of how it works and looks in Tweetie 2 for the iPhone.

First, you type in a new tweet, and pull open the drop down.

Next, you enable the geotag feature, and you'll see a little red pin appear.

You'll see little maps on tweets with locations attached to them.

Click on the map icon for greater detail.

You can do more with your Twitter location too. For example, this website will read your twitter feed and get your latest location, then send it over to Fire Eagle, which is Yahoo’s location service. Fire Eagle can do all sorts of things, but basically it’s just a service that stores your location for other programs to use. So if you want to display your location on your blog, or on Facebook for your friends to see, or anything else you can think of, you can do that, using nothing more than your already existing tweets.

Edit: This post has moved to here: http://ottopress.com/2009/wordpress-settings-api-tutorial/. Take your comments there.

When writing the Simple Facebook Connect plugin, I investigated how the Settings API worked. It’s relatively new to WordPress (introduced in version 2.7), and many things I read said that it was much easier to use.

It is much easier to use in that it makes things nice and secure almost automatically for you. No confusion about nonces or anything along those lines. However, it’s slightly more difficult to use in that there’s very little good documentation for it. Especially for the most common case: Making your own settings page.

So, here is my little documentation attempt.

Making your own settings page

First, add yourself an options page. Code to do that:

<?php // add the admin options page
add_action('admin_menu', 'plugin_admin_add_page');
function plugin_admin_add_page() {
add_options_page('Custom Plugin Page', 'Custom Plugin Menu', 'manage_options', 'plugin', 'plugin_options_page');
}
?>

What this does is quite simple, really:

a. It adds a link under the settings menu called “Custom Plugin Menu”.
b. When you click it, you go to a page with a title of “Custom Plugin Page”.
c. You must have the “manage_options” capability to get there though (admins only).
d. The link this will be will in fact be /wp-admin/options-general.php?page=plugin (so “plugin” needs to be something only you will use).
e. And the content of the page itself will be generated by the “plugin_options_page” function.

Oh wait, we need that function! Let’s go ahead and create that, shall we?

<?php // display the admin options page
function plugin_options_page() {
?>
<div>
<h2>My custom plugin</h2>
Options relating to the Custom Plugin.
<form action="options.php" method="post">
<?php settings_fields('plugin_options'); ?>
<?php do_settings_sections('plugin'); ?>

<input name="Submit" type="submit" value="<?php esc_attr_e('Save Changes'); ?>" />
</form></div>

<?php
}?>

Hang on a minute, where’s all the options? Well, here’s where the Settings API kicks in a bit. Up to now, this has been more or less the same as previous tutorials. Adding the options pages is really quite easy. But now, we’re going to use two new functions.

First, we call settings_fields(‘plugin_options’). This outputs the hidden bits that we need to make our options page both do what we want and to make it secure with a nonce. The string “plugin-options” can be anything, as long as it’s unique. There is another call we’re going to have to make with this same string later.

Next, we call do_settings_sections(‘plugin’). This is going to output all of our input fields. Text input boxes, radio fields, anything we like. Obviously though, we have to tell it what those fields are and look like somewhere. We do both of these things in the next section.

Defining the settings

<?php // add the admin settings and such
add_action('admin_init', 'plugin_admin_init');
function plugin_admin_init(){
register_setting( 'plugin_options', 'plugin_options', 'plugin_options_validate' );
add_settings_section('plugin_main', 'Main Settings', 'plugin_section_text', 'plugin');
add_settings_field('plugin_text_string', 'Plugin Text Input', 'plugin_setting_string', 'plugin', 'plugin_main');
}?>

Here we’ve done three things. Let’s break that down, shall we?

<?php register_setting( 'plugin_options', 'plugin_options', 'plugin_options_validate' );?>

First, we register the settings. In my case, I’m going to store all my settings in one options field, as an array. This is usually the recommended way. The first argument is a group, which needs to be the same as what you used in the settings_fields function call. The second argument is the name of the options. If we were doing more than one, we’d have to call this over and over for each separate setting. The final arguement is a function name that will validate your options. Basically perform checking on them, to make sure they make sense.

Ignoring the validation function for a moment, lets move on to the setting section. This one is actually quite simple.

<?php add_settings_section('plugin_main', 'Main Settings', 'plugin_section_text', 'plugin'); ?>

This creates a “section” of settings.
The first argument is simply a unique id for the section.
The second argument is the title or name of the section (to be output on the page).
The third is a function callback to display the guts of the section itself.
The fourth is a page name. This needs to match the text we gave to the do_settings_sections function call.

That function callback in the third argument should look a bit like this:

<?php function plugin_section_text() {
echo '<p>Main description of this section here.</p>';
} ?>

Simple, really. You can put any HTML you like here.

Now that we’ve talked about the section itself, we need to talk about the fields in that section.

<?php add_settings_field('plugin_text_string', 'Plugin Text Input', 'plugin_setting_string', 'plugin', 'plugin_main'); ?>

The first argument is simply a unique id for the field.
The second is a title for the field.
The third is a function callback, to display the input box.
The fourth is the page name that this is attached to (same as the do_settings_sections function call).
The fifth is the id of the settings section that this goes into (same as the first argument to add_settings_section).

The only difficult one here is, again, the callback. Let’s look at that, shall we?

<?php function plugin_setting_string() {
$options = get_option('plugin_options');
echo "<input id='plugin_text_string' name='plugin_options[text_string]' size='40' type='text' value='{$options['text_string']}' />";
} ?>

Simple. It just gets the options then outputs the input HTML for it. Note the “name” is set to plugin_options[text_string]. This is not coincidence, the name *must* start with plugin_options in our case. Why? Because that is the second argument we passed to register_settings.

The settings pages use a whitelist system. Only valid options get read. Anything else gets tossed out, for security. Here, we’re using a php trick. PHP interprets an incoming GET or POST data of name[thing] as being an array called name with ‘thing’ as one of the elements in it. So, all our options are going to take the form of plugin_options[some_thing], so that we get that single array back, and the array name itself is whitelisted.

Since this is designed with security in mind, we have one last callback to deal with: The validation callback that we skipped earlier:

<?php // validate our options
function plugin_options_validate($input) {
$newinput['text_string'] = trim($input['text_string']);
if(!preg_match('/^[a-z0-9]{32}$/i', $newinput['text_string'])) {
$newinput['text_string'] = '';
}
return $newinput;
}
?>

Here I’m taking a liberty with the code. I’m going to say that our text_string has to be exactly 32 alphanumerics long. You can actually validate any way you want in here. The point of this function is simply to let you check all the incoming options and make sure they are valid in some way. Invalid options need to be fixed or blanked out. Finally, you return the whole input array again, which will get automatically saved to the database.

Take special note of the fact that I don’t return the original array. One of the drawbacks of this sort of approach is that somebody could, in theory, send bad options back to the plugin. These would then be in the $input array. So by validating my options and *only* my options, then any extra data they send back which might make it here gets blocked. So the validation function not only makes sure that my options have valid values, but that no other options get through. In short, $input is untrusted data, but the returned $newinput should be trusted data.

And we’re done. Wait, what?

Yes, the whole point of this exercise is that the options are automatically saved for you. And everything else. You have an options page, you have fields on it, you are validating them… and that’s it. The actual *display* of the page is even done for you. Remember the input we made? It’ll get put into a table with the title on the left side before it, waiting for input.

Another nice thing is that this is easily expandable. For each option to add we:
1. Do a new add_settings_field call.
2. Make the function to display that particular input.
3. Add code to validate it when it comes back to us from the user.

To add a new section, you:
1. Do a new add_settings_section call.
2. Make the function to display any descriptive text about it.
3. Add settings fields to it as above.

One last thing

Sometimes we don’t need a whole page. Sometimes we only have one setting, and it would work well on some existing page. Maybe on the general page, or the discussion page. Well, we can add settings to those too!

If you look through the core code, you’ll find references like do_settings_sections(‘general’) or do_settings_sections(‘writing’), and so on. These you can add on to like any others, getting your settings on the main WordPress settings pages instead of having to make your own.

Just do this:
1. Make an add_settings_section call. The last argument should be “general”, or wherever you want to add your new section.
2. Add fields to your new section, using add_settings_field.
3. You still need to make your own settings whitelisted. To do this, you’ll need to make a call to register_setting. The first argument should be the same as the page name, like ‘general’, or wherever you’re putting your settings. This will let that page recognize and allow your settings to come through.

All the callbacks will basically be the same for this method. You’re just skipping a step of making your own page. Easy.

And there you go. More reading: http://codex.wordpress.org/Settings_API