My Calendar version 1.7.0

My Calendar version 1.7.0 is about to be released. This version contains a large number of significant changes, some of which may have consequences for your existing installation. I have taken every precaution I could, but there are aspects inherent in the automatic update process which cannot easily be tested thoroughly in advance. In preparation for the release, I strongly recommend that you make a copy of your current styles and note the settings of the Upcoming and Today’s Events widgets.

Both widgets have been entirely replaced with the WordPress Multiwidget class, which will allow you to use multiple individual instances of your widgets.

The stylesheet editor is moving from a database-driven editor to a file-based editor, which will increase the cacheability of the plug-in styles, improving performance of your site when using the styles. This also comes with the ability to choose between several different stylesheets.

New WordPress Plugin: My Calendar

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.

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

How NOT to use Post meta fields in WordPress Themes

A little while ago, while working on a site built by another developer, I came across this rather interesting example of how to use custom fields badly in a WordPress theme (abbreviated for, well, brevity):

(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!

WordPress Post Custom Styling

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.

WP to Twitter Update

Version 2.1.1 released.

This is primarily a release targeted at tracking down some nagging problems; but it includes the ability to disable error messages for those suffering from errors even when the plugin is correctly shortening and posting your status updates.

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!

WordPress to Twitter with Cli.gs

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!

Page 1 of 11

Return to Top