The one benefit which it will provide is a little extra time to debug the new OAuth version of WP to Twitter before it becomes the only working version.

There are a lot of complications surrounding the OAuth update — most of them unfortunate. For the first time since I began work on this plugin, I had to remove features. As far as I can tell, there’s no way to operate two separate user accounts with an OAuth authenticated application, for example. As a result, I’ve had to remove the ability to assign separate author accounts for Twitter posting. As development progresses, a way forward may show up — but for now, I just don’t really have another option.

My biggest request at this time: if you can, please decide you’re willing to use this version now, to provide me with feedback so it will work as well as it possibly can when all past versions cease to be functional.

There will be problems; I’m sure of it. I just hope to find them all soon enough.

WP to Twitter Updated to OAuth
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

The specific repercussion will be that every implementation of a plugin will need to be registered with Twitter as a separate application.

This means that the development of WP to Twitter will need to move in a slightly different direction. After pondering a bit, I’m left with four plausible choices:

1. Let the plugin die
2. Implement OAuth for the plugin
3. Build a pass-through web service to act as an application interface with Twitter
4. Associate with a 3rd party web service in the same capacity

These all have downsides, obviously — but I want to lay out my thoughts on each possibility and I’m asking for comments from the users of my plugin on their preference.

Death of WP to Twitter

Although it’s not really my favorite option, I have to acknowledge that it’s plausible. It’s certainly the easy answer — maintaining an even moderately popular WordPress plugin is a lot of free labor. I already spend more time on maintaining than I really should, from a financial perspective, and this may push it over the edge.

Implement OAuth

This would be a fair amount of work for me, although not insurmountable. The real downside to it would be how much work it would be for users — every one of you would have to register one application with Twitter for every site where you installed the plugin. With one site, this may not be a big deal — but I know it could be a real pain for people with more than that.

It’s not without some potential advantages, of course – when you’re registering your own application, you could customize the application name, the home URL for the application, etc.

Build a pass-through service

One way around the Oauth mess is for me to build a separate service which would handle actually connecting to Twitter. WP to Twitter would authenticate with that service, and pass the post off to Twitter. Again, this would be a lot of work — but, more significantly, it would involve some definite expenses.

I’ve been happy to maintain this plugin for not-much-better than free, but when it comes to incurring expenses, I start to feel a bit unexcited. It’s not like WP to Twitter is a commercially viable business, and I have expectations of profit from it — but I’d prefer not to find myself going into the hole because of it. I’d probably need to see an increase in donations to make this feasible.

Use a 3rd Party Service

Obviously, if I can build a service to connect with Twitter, so can somebody else. This is almost certainly the easiest solution which keeps the plugin usable — but it does mean creating a dependency on a 3rd party to keep the plugin functioning. Depending on Twitter is just natural; obviously, if Twitter goes away, the point of the plugin is lost. Depending on somebody else is something I’m less certain of, on the whole. There’s a reason, after all, that the plugin allows for use of URLs without an external shortener.

Give me your thoughts

This is very important to me — I want to know what direction you’d like to see WP to Twitter go. Please let me know! Do you know another solution? Do tell!

And if there are no responses…well, that has a pretty obvious meaning as well.

The future of WP to Twitter
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

Interestingly, the most frequent complaints I’ve heard since launching it were in an area which I had considered to be the least important area of the plugin — what it looks like.

I only did minimal work in setting up the appearance for this plugin; checking whether it basically worked in the default WordPress themes and little else. My assumption was that if anybody needed the plugin, they’d just have to be prepared to customize it to meet their needs. There was no reasonable way I could set it up to mesh with all possible themes, after all!

But apparently, in order to have the plugin be generally accepted, people need it to have “a look.” Most advanced users will probably change it; but I clearly hadn’t considered the more beginner users, without sufficient CSS knowledge to readily customize the output.

What’s really interesting to me about this situation, however, is not whether the plugin is accepted, popular, or heavily designed; that’s just an example. I was intrigued to observe in my own development process an approach which almost entirely ignored what the product looked like. From start to finish, I was really thinking about whether the plugin produced well-structured HTML and whether the various functions involved in producing information worked well.

I just never thought about design. And why would I? If I can’t predict what context the plugin will be used in, why should I design it at all, beyond making the basic functionality clear?

It’s an interesting question; from my perspective, as a fairly advanced WordPress developer, I honestly prefer plugins I use to have absolutely minimal styles, and for me to be able to disable those styles at will so that I can replace them. However, WordPress has a very broad user base. Most of those millions of users probably expect that they can install a plugin and immediately make use of it — and any changing of colors or reskinning to better match their design is purely optional. For those users, I really should be providing something which can be immediately useful.

It actually does come down to usability: advanced users can do what they want with the calendar design regardless of how extensively I’ve set up styles. Beginning users, however, may not be able to fix anything that I’ve left unresolved, or not fully tested. In order to provide the best usability, I need to consider those users, as well.

Having determined that it does make sense to actually design the plugin’s output, but also knowing that there’s no reasonable way I can design it to match all themes, I do have to make a firm decision about what the basic color scheme for the plugin will be. Originally, I’d used a basic, Kubrick-derived color set. Now? Well, the sensible thing seems to be to consider branding; set it up using my own website’s color scheme. It may be subtle, but it will convey my identity, even without my name or URL. That seems worthwhile.

Guess I better get to work!

Form over Function? Never thought about it…
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

Version 1.3.0 released. Numerous bug fixes and new features.

I just launched the first public draft of an online calendar plugin I’ve been working on for a while. It’s based on a plugin from Kieran O’Shea, Calendar, but has been adapted extensively to better suit my own needs.

Hopefully, it’ll also suit other people’s needs.

• Read more about My Calendar.
• Download My Calendar.
• View a sample installation.

Please leave comments or questions at the My Calendar support page; leave feature requests on the feature request page!

New WordPress Plugin: My Calendar
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

Continuing updates: Cli.gs gets a temporary stay of execution. Keep watching for further news — I may end up making these changes after all, but for now I’ll wait and see.

The Cli.gs URL shortening service is due to be closed down on Sunday, October 25th. At this time, the service will stop accepting new short URLs and generating statistics, but will continue to forward visitors at least through the end of November.

What does this mean for WP to Twitter?

Shortly before October 25th, I will release a very important update to WP to Twitter which will encompass the following changes:

1. I will remove support for new Cli.gs shortened URLs.
2. To continue offering choice, I will add support for at least one additional shortener.
3. Users with Cli.gs as their selected shortener will be given a choice what shortener they’d like to switch to.
4. If no choice is made, users will be switched to un-shortened URLs

Additionally, I aim to add support for custom shortened URLs – URLs shortened on your own domain. However, this may not happen by October 25th.

WP to Twitter update: Cli.gs to be shut down
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

Not a bad way to get a handle on WordPress plugin authoring. There may be a better way to approach the subject, but I can’t honestly say that I know what it might be.

The fact is, WordPress plugins are incredibly powerful and cover an enormous breadth of possibilities. As the guide indicates, the WordPress plugin API is essentially a WordPress-specific method of accessing the entirety of the PHP programming language. If you can do something with PHP, you can probably do it in a WordPress plugin.

The book has a basic assumption that you’re already fairly sophisticated in your use of PHP programming. Rather than hold your hands through PHP logic, the important information provided in this book is about how to make use of the WordPress specific functions which will allow your script to tie to WordPress — and the key information that plugin authors need to be responsible for the security of their own scripts.

This is an extremely important piece of information, and can’t be emphasized enough. Probably the biggest flaw in this book is that plugin security isn’t highlighted sufficiently. It’s not that the book doesn’t state clearly that plugin authors need to take care of security, but it doesn’t do it on every single page in six-inch bold type….

But I digress.

On the whole, you can learn a lot from this book, whether you’re a beginner at WordPress plugin authoring or not. The breadth of WordPress plugin capabilities means that most experienced authors don’t know everything, so there’s almost certainly something here for you — but it starts simple, and within the first 30 pages you’ll already have a usable, practical plugin written.

Review: WordPress Plugin Development: Beginner’s Guide, by Vladimir Prelovac
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

(The original also did this for meta keywords and meta descriptions — but the demonstration of this “logic” only requires one field.)

 
<? if (is_front_page()) { ?>
	<title>Handwritten title</title>
<? } elseif (is_page("page-name")) { ?>
	<title><?= get_post_meta(334, 'meta_title', TRUE); ?> | <? bloginfo('name'); ?></title>
<? } elseif (is_page("page-name-2")) { ?>
	<title><?= get_post_meta(383, 'meta_title', TRUE); ?> | <? bloginfo('name'); ?></title>
<? } elseif (is_page("page-name-3")) { ?>
	<title><?= get_post_meta(381, 'meta_title', TRUE); ?> | <? bloginfo('name'); ?></title>
<? } elseif (is_page("page-name-4")) { ?>
	<title><?= get_post_meta(383, 'meta_title', TRUE); ?> | <? bloginfo('name'); ?></title>
<? } elseif (is_page("page-name-5")) { ?>
	<title><?= get_post_meta(387, 'meta_title', TRUE); ?> | <? bloginfo('name'); ?></title>
<? } ?>

And so on. For approximately 40 separate pages. It made my brain hurt. For reference, the exact same thing — for all pages on the site — could have been accomplished (with better fallback conditions, in fact) with this code:

 
<?php if (get_post_meta($wp_query->post->ID, 'meta_title', true)=="" && is_page() ) { ?>
	<title><? wp_title('|', true, 'right'); ?> <? bloginfo('name'); ?></title>
<?php } else { ?>
	<title><?php echo stripslashes(get_post_meta($wp_query->post->ID, 'meta_title', true)); ?> | <? bloginfo('name'); ?></title>
<?php } ?>

Now, the original code may actually look cleaner — it does, after all, have fewer functions and fewer variables. However, the second example is a hell of a lot more maintainable.

If you add a new page to the site in the first example, you have to:

1. Create the new page.
2. Add a custom field with the title.
3. Check the new page’s ID.
4. Find the theme file which contains the meta data references.
5. Add a new line in the elseif loops which references your new page first by slug and then by ID

With the second example, you simply:

1. Create the new page.
2. Add a custom field with the title.

No coding, no PHP, no editing themes — it just works. Well, isn’t that handy? This is just basic good coding practice: make your code reusable. There’s absolutely no reason to code something into your WordPress Themes which is not readily transportable unless you’re doing yourself a favor by avoiding an unnecessary server call by hard-coding the site name or other known elements.

The basic difference between these two examples is simple: the first requires you to hard code the ID and page slug for each example; the second grabs the post ID from the existing post object. The second example also has a fall-back if no information has been entered in a given custom field — which is lacking in the original code.

Word to the wise: save yourself some work!

How NOT to use Post meta fields in WordPress Themes
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

Current Version: 1.2.1

Download WP Post Styling.

Read more about this plugin.

Support this Plugin

New in Version 1.2.1:

• Added ability to delete CSS from the style library

New WordPress plugin: WP Post Styling. The plugin serves only one purpose: to create a place to add custom styles which will only apply to the current page or post in your WordPress blog.

Although not widely used on the internet, it’s a valuable magazine design technique to give each article a unique look and feel. A look and feel which shows the face of that article in a light which best represents the subject, topic, or style.

This plugin is intended to make that kind of post-by-post styling simpler.

It’s not that you can’t readily do this in WordPress — either by using a theme which applies style hooks for unique articles, by utilizing WordPress conditional functions to check whether a given page is active, or by whatever other means you might imagine — but this makes it much simpler, since you can simply enter the desired styles into a textarea directly in the post.

Comments and requests should be made at the WP Post Styling home page.

WordPress Post Custom Styling
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

Current version: 2.1.1

• Download WP-to-Twitter
• Follow me on Twitter!
• Support this plugin!
• Support Questions and FAQ

2.0.0

• Fixed bug introduced in WordPress 2.9 where logged in users could only edit their own profiles and associated issues.
• Fixed bug which caused #url# to repeatedly be added to the end of tweet texts on reactivation or upgrade.
• Fixed bug which generated shortener API error messages when no URL shortener was used.
• Fixed bug which prevented display of URL on edit screen if no URL shortener was used.
• Added Spanish translation courtesy of David Gil Pérez
• Made so many language changes that aforementioned translation is now terribly out of date, as are all others…
• Added ability to restrict posting to certain categories.
• Added option to dynamically generate Google Analytics campaign identifier by category, post title, author, or post id.
• Added option to configure plugin to use other services using the Twitter-compatible API.
• Added support for YOURLS installations as your URL shortener. (Either local or remote.)
• Redesigned administrative interface.
• Removed use of Snoopy and alternate HTTP request methods.
• Discontinued support for WordPress versions below version 2.7.
• Major revisions to support checks.
• Version jumped to 2.0.0

See the change log at WordPress.org.

Comments on this post are closed; please make comments at the WP to Twitter home page!

WP to Twitter Update
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

About WP-to-Twitter

Download WP-to-Twitter

Technically, this plugin has been available from the WordPress plugin directory since last Monday, but today is it’s official launch. This is for two reasons: first, it gave the plugin a week to “shake out the bugs,” so that the official launch could be as stable as is reasonably possible.

Second, it’s my birthday, so I’ll be able to remember when the plugin launched. Isn’t that sweet?

The plug-in is pretty straightforward: it posts a status update about your new WP post to Twitter, passing by Pierre Far’s Cli.gs URL shortening service on the way. If you have a Cli.gs API key, you’ll get the added bonus that your Cli.gs will automatically show up in your Cli.gs account, so you can track the statistics of that Clig right from the beginning.

By default, the plugin will take a chunk of text you’ve defined and your post title and truncate them to an acceptable length (including your Cli.gs post URL) to send over to Twitter. However, you don’t have to just accept this stock text: you can custom author your Tweet for every post, using the WP to Twitter custom field in your post authoring interface.

Read more about WP->Twitter

Download it at WordPress!

WordPress to Twitter with Cli.gs
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design