larryaronson.com

Articles

GoDaddy Update Question

A client friend recently wrote:

I got an email from go daddy and spoke to an agent about updating [the website].

I didn’t understand much of what he was explaining but he said it was not that hard to do. He said I need to back up and move the content over to the new platform. Something called a linix C panal web hosting.

I answered:

GoDaddy is trying to get you to move [the website] into their new-ish account management structure in order to make it easier to sell you additional hosting products and services. This is separate from your domain name registrations with GoDaddy which won’t have to be renewed for another couple of years.

  • You DO have to renew your Web hosting agreement for [the website] by Sept. 8.
  • You don’t have to change the hosting plan.
  • It would be a good idea to backup [the website] in any case.

Your current hosting plan is called, “Economy Classic Hosting Linux” and GoDaddy wants to move/upgrade you to “Economy Linux Hosting with cPanel”.  In anticipation, they’ve already setup the new account with a dummy website and a separate username/password. The new plan would cost you $6.99/mo whereas your current plan is $5.99/mo.

Linux is the preferred operating system for Web servers. It’s very similar to MacOS – like two sisters who went to different schools and dress differently. cPanel is software for managing an account on a Linux server. Like the Systems Preferences application on a Mac, it has a number of panels for changing your settings and adding/removing features.

If you have no interest in adding new features to [the website] – i.e: email accounts, e-commerce packages, premium support – don’t upgrade, just renew the current plan. I can help you with that.

Don’t let GoDaddy persuade you that [the website] needs more than “economy” level resources. Although it is a gallery website, all of the images are optimized for quick loading and minimal bandwidth. The web pages are simple HTML, requiring no extra resources on the server for the amount of traffic you anticipate.

About WordPress Themes

What to Choose, How to Choose.

There’s a never ending discussion about WordPress themes in forums I visit and meetups I attend. Paid vs. free; custom clones vs. child-parent themes; large frameworks like Genesis vs. stand-alone themes like Twenty Eleven. Here are my thoughts:

•••

Happy Birthday WordPress

WordPress is 9 years old today and has announced the availability of the first release candidate (RC1) of the next version, 3.4, which I’ve just installed on my local MAMP stack.

So far, there’s no sign of a new “TwentyTwelve” theme. However, there is a new theme previewer/activator that allows an administrator to set a number of theme options and see how they look before saving the options and activating the theme. It’s really nifty. I’ll have more on the new version after the weekend.

But, I also wanted to share my excitement on attending a wonderful event last Thursday and getting to meet Matt Mullenweg, the creator of WordPress and CEO of Automattic. The event was the first in a series of monthly “fireside chats” organized by Pandodaily.com. Matt was interviewed by Sarah Lacy, the founder and editor-in-chief of PandoDaily. It was a long, free-wheeling and thoroughly enjoyable interview and Q&A. My thanks to Howard Greenstein for  getting me in to the event.

Happy Memorial Day!
Larry Aronson

 

Where’s My Query?

Working With WordPress Hooks

When you’re dealing with custom post types you eventually come to the question of what should show up on an archive or search results page (SRP). Say the custom post types are created by a plugin or are built into a special-purpose theme like property listing posts in a real estate theme. How do you know whether or not they’ll show up on an SRP?

The answer is found in the question.
Specifically, the SQL select statement – the request that WordPress sends to the blog’s database. Unfortunately, that statement isn’t readily available to the code in the theme’s template files. The main database query for a WordPress page happens before any of the code in the theme folder is run.

We need to use a WordPress hook to capture the SQL statement before it’s sent to the database. Then we can display it later anywhere we want to; like at the bottom of a Search Results Page. (OK, I’ve read enough; just give me the code.)

The WordPress hook to use is called, posts_request. WordPress passes the main SQL select statement to any filter function registered at that hook. That function can modify the query but, for now, we can just store a copy of it in a global variable. This hack requires editing your theme’s functions file, so make sure you take a backup copy first.

Add the following code to the theme’s functions.php file.

function my_posts_request_filter( $input ) {
     global $my_sql_statement;
     $my_sql_statement = $input;
     return $input;
 }

You can rename the variables and the function itself, if you want; just be consistent when you use the global variable later in your template files.

The function has to be registered to run at the post_request hook. Add the following line to the functions.php file. It can go either before or after the function definition you just entered.

add_filter( 'posts_request', 'my_posts_request_filter', 9999 );

The first argument of the add_filter function is the name of the hook and the second is the name of your function. The third argument is the priority. This we set to a large value because we want our function to run after all other functions registered at that same hook, in case any of them modify the SQL statement.

Save  functions.php and load a page from the site just to make sure you’ve not made any stupid syntax errors. Your site should be unchanged by the new filter function; all it’s doing is saving one more global variable in the WordPress sea of data objects available to the theme.

Now we do the same to instruct WordPress to display the SQL statement at the bottom of a SRP page. Add the following function to the functions.php file:

function print_my_sql_statement() { 
     global $my_sql_statement; 
     if (is_search()) print_r($my_sql_statement); 
}

The first line  makes the global variable, $my_sql_statement available to the function. The second prints the value of the global on the condition that the current page is the result of a search.

To get this code to execute at the end of a page, you add it to the wp_footer hook:

add_action( 'wp_footer', 'print_my_sql_statement', 9999 );

I found this technique very helpful in learning how the WordPress functions, wp_query() and get_posts(), process their arguments, which can get rather complex when trying to include/exclude posts based on the values of custom fields. Understanding that process made it possible to use another WordPress hook, pre_get_posts, to exclude some custom post types from site searches based on their custom field settings. I hope you find this helpful as well.

Happy Hacking,
Larry Aronson

 

Photo Credit: http://www.flickr.com/photos/widnr/6544914763/

The word from WordPress was that version 3.3 would arrive sometime this week. Well, It’s here and it’s a major release. Whereas version 3.2 was mostly a bug fix and stability release, version 3.3 introduces new tools for all users from admins to authors and subscribers.

I’ve been working with the beta and release candidates here on this blog and the improvement that has me most excited is the unified drag-n-drop media loader. In version 3.3, the four buttons for image, video, audio and media are gone;  there’s only one Upload/Insert media tool.


Post editor tool bar with unified media tool

 

Clicking the Upload/Insert button pops up the new loader which defines a space for dragging and droppin one or more files. You can see this in the following screenshot showing me uploading the following screenshot into this post following this sentence.

 

 

The uploader then smartly figures out what type each file is and displays them in the familiar show/hide popup panel. But, it keeps the drag-n-drop window available for more quick uploads into the gallery. Editors will appreciate this thoughtful touch.

The second new feature I like is the Welcome to WordPress 3.x dashboard page that you’re returned to after automatically upgrading to a new version. It describes the new features. It’s the version’s README file located in your blog at /wp-admin/about.php. It’s very friendly.

 

It part of a package of new features that make the dashboard a more friendly place for the millions of non-technical, website owner/operators who are using WordPress as personal publishing platforms (like many of my clients.) In the same manner, version 3.3 pops up a tip window the first time you try a dashboard feature or visit an admin page.  And, throughout the dashboard, there are improvements and added touches that’ll make it more application-like. According to the about page, these are:

  • Combined toolbar and admin bar — They’ve finally gotten it right and it can be customized by theme developers
  • Fly-out dashboard menus — No more accordions. The sub-menu extend out horizontally
  • Screen design fixes — To take into account tablets and other non-pc devices and screens
  • Better  help information — A frame open at the top of the page with tabbed sections and related links

For theme developers, WordPress version 3.3 adds new APIs for the editor and dashboard admin screens supposedly making it easier to customize the back end for special themes and applications. It also include the complete jQuery UI stack and makes good use of it. This more or less standardizes WordPress’ JavaScript framework. It’s a good move, in my opinion. Other JavaScript frameworks such as MooTools, Prototype and Scriptaculous may have richer behaviors to attach to page elements, but they are also prone to causing plugin conflicts.

Anyway, Based on my first impressions and a few hours spent with it, I con recommend updating your WordPress to version 3.3 soon, especially if you regularly write posts with images and other media attachments. As always, back up your WordPress files and database before you upgrade your website. If you’re using non-standard plugins or customizations, ask your web developer if they are compatible with the new version. And, don’t forget that you can aways get answers from the WordPress Support Forums.

Happy Blogging!
Larry Aronson

 

 

Avoiding the Post Editor’s HTML Mode

Good News Everyone! The post/page editor is getting an upgrade with the soon-to-be-released version 3.2 of WordPress. This solves the problem of disappearing Google maps and YouTube videos. Both rely on iframe elements to embed the contents of one webpage into another. Unfortunately, the current version of WordPress’ built-in editor doesn’t like iframes* and you have to limit yourself to working in the editor’s HTML mode. Once you switch to Visual mode, the iframe elements are stripped out of your post or page and the map or video disappears.

In WordPress 3.2RC1 (aka: Release Candidate 1) currently running on this blog, iframe elements are saved as I switch between the editor’s Visual and HTML modes. So are most of the new HTML5 tags including: the canvas and video elements – but not the audio element! This has been reported as a bug.

In the discussions on blogs and WordPress forums, one of the solutions for working with iframes was to use a general purpose shortcode to work around the editor’s restrictions. This approach is worth a second look because it gives authors the capability to embed anything they damn well please in a post without ever having to use the editor’s HTML mode – a big plus for some of my clients who go totally cross-eyed whenever they look at HTML.

The Macro Shortcode

Say you want to show a Google map in a post about an event happening in your neighborhood park. Getting the map is easy:

Example of using Google Maps embed code

The idea behind the Macro Shortcode is that the embed code from Google (an iframe element) is pasted into a custom field for the post. The name of the custom field can be something descriptive, like “google-map”. In the WordPress editor, inside the Custom Fields box, click on the “Enter New” link to create a new custom field with the name, “google-map”.

inserting embed code into a custom field

Now, you can place a shortcode anywhere in the content of a post or page where you want the map to appear:

[macro name="g00gle-map"]

To make this work, you need to define the macro shortcode and add it to your theme. The following PHP code added to your theme’s functions.php file does the trick.

// macro shortcode — a function to insert the value of a custom field into a post
// [macro page=<page_id> name="post-custom-field-key"]

function my_macro( $atts, $content = null ) {
    extract(shortcode_atts(array( 'page'=>'', 'name'=>'' ), $atts));
    global $post;
    if (!is_numeric($page)) $page = $post->ID;
    return get_post_meta($page, $name, true);
}
add_shortcode('macro', 'my_macro');

Make sure you first backup the file. See the WordPress Codex for more information on the get_post_meta() and add_shortcode() functions.

The macro shortcode will also accept a post or page id parameter which gets a custom field from some other page or post. This is handy when a small block of marked up content is needed in more than one place on the site. For example, to create a customized signature macro that can be added to the ends of posts (like you do with emails,) you could add a custom field to your bio page. Let’s say this bio page has an id of  3 and you’ve created a custom field attached to that page, named it “signature” and gave it the following value:

<p style="text-align: right; color: red;">That's All Folks! 
&mdash;<a href="http://loonytunes.fun/bios/bugs"><em>B.Bunny</em></a></p>

Now, all you have to do is insert this shortcode at the end of your posts:

[macro page=3 name="signature"]

and it will be replaced with your red, right-aligned sign-off message.

 

 

* TinyMCE, the WordPress built-in editor, is a JavaScript program that runs in the user’s browser. It doesn’t like the  iframe element because it’s not valid xhtml which the editor is compelled to output when operating in the Visual mode. In the HTML mode, it doesn’t care; you’re on your own.

This blog in Twentyeleven themeI just upgraded this blog to WordPress version 3.2, beta 1, which was released to the wild a couple of days ago (see the announcement.)  Here are my first impressions:

WordPress has introduced a new “default” theme, Twentyeleven. It’s a variation of the Twentyten theme introduced with version 3.0, with a slightly cleaner look. I put default in quotes because neither theme is really a default. Both Twentyten and Twentyeleven are better characterized as showcase themes. Both override several of WordPress’ built-in default settings and demonstrate how to use some of the newer features for specific design objectives such as featured images for custom page headers. [Note: this blog is using the theme, Tabula Rosa by Leo Newball, Jr. Click the thumbnail above to see what it would look like in Twentyeleven.]

WordPress Dashboard

A welcome addition to Twentyeleven is a Theme Options dashboard page that provides control over link colors and whether to display the sidebar on the right, left or not at all. The Custom Headers and Background Colors option pages from Twentyten have be duplicated in Twentyeleven.

One new feature all WordPress authors should welcome in the revamped, full-screen editing mode. It’s has full editing features including a field for the title, a save/update button, tabs to switch from visual to HTML mode and an abbreviated toolbar with icons for bold and italic, ordered and unordered lists, blockquotes, images and links. Strangely, the post editor toolbar has new icons that appear duller and less interesting then before:

The post editor for WordPress 3.2

Post Formats

Post formats in WordPressTwentyeleven adds big-time support for post formats, which were introduced in version 3.1. Post formats are like categories except that they refer to the content’s format rather than its subject matter. A post can be in only one format chosen from the predefined list. Where Twentyten moved much of the post processing to template files based on post type: loop.php, loop-page.php, loop-single.php and loop-attachment.php, Twentyeleven has template files specific to post formats: content.php, content-aside.php, content-gallery.php, content-link.php, etc.

HTML5

Twentyeleven is an HTML5 theme. So is Twentyten but, whereas Twentyten just has an HTML5 Doctype declaration, Twentyeleven goes further by using the new HTML5 sectioning elements: nav, header, hgroup, article and footer. A conditional statement loads in an HTML5 shim for people using versions of Internet Explorer before IE9. It would be nice to add these new document elements to the paragraph menu on the editor’s toolbar.

Speaking of IE, the announcement states that WordPress 3.2 will not support IE6 — Yippie! I’m guessing that this means the Dashboard will not work well in IE6 but, if you make the effort and construct a good CSS stylesheet, the public front end should work. To help, Twentyeleven ids the html element so that you can construct specific CSS rules for IE6 users, such as:

#ie6 div.content { ... }

The Dashboard’s been given a facelift. Everything works the same but looks prettier due to new fonts and some CSS3 goodies used to great effect—background gradients, box shadows, rounded corners and text highlights. The little AJAX wrinkles have been smoothed out and the interface elements respond quickly.

I find the small changes made in the Dashboard pleasing and send kudos out to the designers who keep making a good user experience better. One disappointment is that they haven’t yet addressed the shortcomings in the way WordPress manages media attachments. Instead of having a separate database table, media files are represented by attachment posts in the main post table, reusing post fields for image caption and alternate text information. A rebuilt media manager was supposedly slated for a 2.9.x release but kept getting put back. I look forward to progress in this area.

The upgrade was simple and straightforward, as is usual with WordPress. Since there’s no automatic install for beta releases, it requires an FTP program to upload the new files. I highly recommend backing up everything first. While not ready for important production websites, this first beta of version 3.2 is worth installing on a test blog just to get an early look at the Twentyeleven theme and begin testing the functionality of post formats.

Overall, editing this post under WordPress 3.2 has been solid. I’ve not encountered any bugs or glitches. WordPress.org states that 3.2 is a performance upgrade. This is only one post and on a new blog so I can’t measure or verify any improvement based on my experience so far. I’ll take their word for it. Thanks WordPress.

Crafting a Custom “Popular Posts” Widget

top ten blocksA client wanted to list the blog’s most popular posts in the sidebar. There are many plugins available that will provide a widget for this task. Most are based on comment count as this is the metric that WordPress stores with each post record in its database. Some of the more sophisticated plugins make API calls to other services, such as Twitter and Google, to gather ranking data.

But nothing worked quite right for this client who had become a proficient Google Analytics user as well as a ardent Twitter user. I couldn’t find a popular posts plugin that would reliably match her subjective sense of popularity. I finally sent an email saying: “You want your readers to see your best stuff, in that respect, the numbers can provide guidance but your own judgement is the best metric.” I promised to figure something out that would allow the management of a Top-Ten Posts lists.

Rather than write a new sidebar widget, I decided to write a shortcode which could be used in a sidebar text widget to display the content from a specific page. Then my client could simply edit a page containing an ordered list of permalinks to the most popular posts and it would appear in the sidebar widget. It could also be used in other posts or pages on the site.

How to Build a Sidebar Page Widget

To start, create a new static page with a title like, “Popular Posts”. Enter an ordered list of permalinks to other posts for testing.

You need to add a function to your theme’s function file, functions.php, that will output the contents of a page when called from the shortcode. Make sure you backup functions.php before you make any changes! WordPress has built-in functions for getting the contents of a page. Use get_page_by_title( ) to fetch the page by its title. Here’s the code for the function:
function my_show_page( $atts, $content = null ) {
extract(shortcode_atts(array( 'title'=>'' ), $atts));
if ($title != '') {
$page_data = get_page_by_title( $title );
return $page_data->post_content;
}
else {
return '';
}
}

The first two lines are the standard setup for a shortcode. The parameter, $atts, will contain the shortcode’s parameters. In our case there is only one parameter, the page’s title which is extracted by the second line of the code. Setting the variable $content to null allows us to place the simple shortcode:

[showpage title="Popular Posts"]

wherever we want to display the content of the page “Popular Posts” .

The body of the function is a simple if statement that makes sure a title is provided, then goes and gets the content of that page and returns it. The content is returned unfiltered. That is, it’s unaffected by any plugins (e.g: ShareThis) or other code that modifies content.

The shortcode must be registered to make it available for use. This is just a short command that also goes in the theme’s function file:

add_shortcode('showpage', 'my_show_page');

It can go either before or after the definition of the my_show_page function. I usually place it after the function along with comments to guide any future programmers who may work on my clients’ sites.

Shortcodes are not enabled by default in text widgets because of security concerns. Sidebar text widgets are places where people often embed code clipped from outside sources. The concern is that such embedded code might contain a shortcode that could cause a conflict. This is usually not a problem for smaller, personal blogs. Here’s the command to enable shortcodes in text widgets:

add_filter('widget_text', 'do_shortcode');

Add the above to your functions file, save it and test the blog in a separate browser window to be sure it’s still working. Errors in a theme’s functions file will usually crash the public portion of a WordPress blog, but will leave the admin dashboard in working order.

Lastly, add a text widget with the shortcode to your sidebar. Here’s a screenshot from my client’s site illustrating this.

Text Widget with a shortcode

For your convenience, here’s the entire block of commented code that I added to my client’s function file:
/**
* Create a shortcode to display a page's content */
//
// [showpage title="page_title"]
//
function my_show_page( $atts, $content = null ) {
extract(shortcode_atts(array( 'title'=>'' ), $atts));
if ($title != '') {
$page_data = get_page_by_title( $title );
return $page_data->post_content;
}
else {
return '';
}
}
// register the shortcode
add_shortcode('showpage', 'my_show_page');
//
// Enable the use of shortcodes in text widgets.
add_filter('widget_text', 'do_shortcode');

Now that we see how easy it is to get formatted content into a sidebar widget, perhaps you have some ideas on what can be done with custom shortcodes in sidebar widgets. If so, please share them by leaving a comment below. Thanks.