We’re excited to announce the opening of Oomph Boston, located in the heart of Harvard Square. One Mifflin Place in Cambridge is already buzzing with a team of talent headed by new Creative Director Patrick Richardson.

This second location – an extension of our home office in Providence – allows us to be closer to many of our core clients, like NESN and Boston College. Plus, with so many distinguished colleges and universities in our new backyard, our Boston office gives us access to the brightest minds in the field as we grow our company. Today, the energy happening around web development is intensifying wicked fast, and Boston is one of the hubs leading the charge. By basing a team in Boston, we’ve been able to readily share knowledge and demonstrate leadership in the WordPress, Drupal and PHP communities in and around the region.

Our new presence in Boston is very exciting. We are fortunate to be growing and expanding, and this milestone is one we’ve been anxiously awaiting. The Boston tech scene is hot and Oomph is ready to dive right in!

- Chris Murray, President

As we expand our space, we plan to expand our team as well. Oomph is currently hiring outstanding developers (read: superheroes) to join our team and continue to make the exclamation point in our logo well earned.

Developers Wanted

Upon arriving, I checked in and had a few hours to stroll the grounds and mingle with other attendees – quickly realizing I was among some of the brightest minds in the WordPress community. Throughout the afternoon, developers from companies such as Time Magazine, Dow Jones, O’Reilly Media and NBC Sports began filtering onto the property.

The event officially kicked-off a few hours later with Matt Mullenweg’s inspirational keynote address, which left me with the overwhelming awareness that I was involved in something very special. Over the last few years, WordPress has achieved an impressive following and some serious momentum. The platform has evolved from blog management to content management, and it’s quickly gaining traction with developers as an application framework. What was once a simple blogging platform now powers 16% of the Internet. Tony Schneider, CEO of Automattic, followed Matt’s address with this real-time map illustrating some of the remarkable usage statistics related to WordPress, and then he concluded with his exciting vision for the future of the platform.
The next two days were all about the training. Topics included caching, taxonomies, A/B testing, coding standards, advanced theming, the rewrite API, and other intensive subjects relevant to working with VIP. These sessions were augmented by interactive examples presented on a Debian server virtual machine that allowed everyone to hack along and directly attack the code with the very people who helped create it. Mo Janda introduced a

tool called the VIP Code Scanner, which I highly recommend to anyone working on the platform and looking for a useful way to audit their code. Michael Fields of The Theme Team shared his expertise, including advice on leveraging The _s Starter Theme that gives theme designers a “1000-hour head start.” During one of my favorite talks – Mike Adams’ session on XML-RPC – the Automattic Social Team made an announcement revealing the new RESTful API now available on WordPress.com.

Direct access to the Automatticians along with members of the VIP community created both a great social dynamic and an opportunity to learn new strategies and discuss concepts utilized by other developers. The relaxing atmosphere of wine country, the rigorous daily seminars and the nightly networking opportunities together resulted in an amazing educational event. The intimate and interactive setting contributed greatly to making the experience wholly satisfying. I would like to extend a special thanks to my employer, Oomph, for making my attendance at this incredible training possible. I can only hope my growth as a developer on the highly-successful VIP platform will consist of more equally gratifying opportunities in the future.

After providing a brief overview of different caching methods, I spoke in depth about using fragment caching to improve performance and provided numerous examples taken from client projects. Fragment caching is the practice of abstracting elements of a site, such recent posts or navigation menus, and saving them for reuse. It could be that a specific element is complex to generate, or that it appears on numerous pages across a site; in either case, avoiding the need to recreate these elements can provide significant performance benefits.

The slides I used and video of presentation are embed below.

Key responsibilities will include active contributions to Oomph’s brand, marketing, and creative culture, instilling engaging design as a core philosophy across the entire company, and developing creative approaches for all aspects of client engagements.

An ideal candidate will have experience leading small creative teams in an agency environment, a desire to work on creative solutions for sites and apps with massive audiences, and a passion and drive to create “wow” design and deliverables.

Interested? Learn more about the position.

All Open Positions at Oomph:

Creative Director

PHP/MySQL Developer

WordPress Developer

Identical terms that appear in two different taxonomies are still the same term.

Yet, They are treated by the WordPress interface as if they are not.

The Problem

For a simple example, suppose we had two taxonomies, fruits and colors. In the fruits taxonomy, we had the following terms:

Apple
Orange
Banana

And in colors, the following:

Red
Orange
Yellow

Suppose we wanted to change all of the colors to use lower-case instead:

red
orange
yellow

We now see that the change to the term “Orange” is also reflected in the fruits taxonomy:

Apple
orange
Banana

This is obviously not what we want. Conceptually, Orange the fruit and Orange the color are distinct entities, but to WordPress, they are the same thing.

The Project

The problem above was fully fleshed out while developing one of our most recent and most challenging projects. This project required us to be able to translate everything seen on the screen for an end-user into 5 distinct languages: English, French, Italian, German and Dutch; as well as into 2 variants of English, UK and US, for a total of 6 different translations for each string seen by the user. Besides regular translateable strings that were coded into the theme using the WordPress I8n API, we also had to manage translations for certain taxonomies, such as category.

Since these strings would be coming from the database, employing the WordPress I18n API for translating these strings via .PO/.MO files would not have been the correct way of approaching this problem, as then we would have been passing variable values into the __() suite of functions. This poses a problem since the scripts we use to generate the .POT files to be translated would not know which string is actually in need of translation.

Another down-side of having used PO files for translating these strings would be that there would be no separation of language category taxonomies, which means that per-language category terms would have to mirror each of the other ones at all times, and there would be no opportunity for using a foreign-language term that does not appear in either the base (untranslated) taxonomy.

In order to achieve translated taxonomies, we first created a taxonomy, “languages” that would store each of the languages that were used within our system, with the terms:

The -language suffix on these term slugs was a necessity because of slug collisions with another taxonomy.

   en-uk-language - English (UK)
   en-us-language - English (US)
   fr-fr-language - French
   nl-nl-language - Dutch
   de-de-language - German
   it-it-language - Italian

The terms from this taxonomy were in turn used to define a taxonomy for each one of the taxonomies we needed to translate:

   category_en-uk-language
   category_fr-fr-language
   ...

And so forth. For each term used in one of these translated taxonomies, the helpful “description” field is used to link it back to its untranslated base:

As an aside, the hijacking of the “description” field as a substitute for proper Taxonomy metadata is a time-honored WordPress hack that is used by many themes. The alternative would be to store taxonomy metadata in the options table, but this method does not scale as well, since it bloats the options table and would require two database reads to pull meta data out for every term. Another alternative for dealing with this issue would be to use a custom table, but this sort of thing is simply not allowed in the WordPress.com/Wordpress.com VIP environment, adds extra complexity, and would still require extra database reads to pull the taxonomy meta data.

In (US) English, we might have a category structure akin to the following:

Job Market
-- Pay
Advice
-- Insight
-- Resumés

Which in French, for example, would look like:

Marche de l'emploi
-- Salaires
Conseils
-- Aperçu
-- CV's

But also might have slight differences for UK English vs. our base theme language of US English:

Job Market
-- Salaries
Advice
-- Insight
-- CV's

Looking at our category structure above, we see that both UK English and US English are using “Job Market” as a category, but UK English and French both use the term “CV’s” instead of the US English “Resumés.”

Suppose we wanted to change the UK English category to read “Job market” instead, with the second word in lower-case. We would make this change using the edit terms screen in the WordPress back-end. Now we look at the US English version of “category”:

Job market
-- Salaries
Advice
-- Insight
-- Resumés

Whoah! Back the truck up! That change also got applied to the “Job Market” term in the US English category. What happened here?! It seems that even though the “Job Market” category appears twice in separate category taxonomies, changes to one will affect the other. We’d encounter the same problem if we tried to change French “CV’s” into “CVs”, without an apostrophe: the change will also propagate to the UK English category name. This is definitely not what we want.

Problem Details

The complication here arises from the WordPress taxonomy data schema. There are two tables in the WordPress schema that are responsible for storing taxonomy data:

wp_terms

and

wp_term_taxonomy

A third table, wp_term_relationships links taxonomy terms with the posts to which they are attached, but I don’t necessarily consider it part of the taxonomy data storage system.

The fields of interest are:

wp_term_taxonomy.taxonomy
wp_term_taxonomy.parent
wp_term_taxonomy.description
wp_terms.name
wp_terms.slug

  and finally, the relating field: 

wp_term_taxonomy.term_id = wp_terms.term_id

This is a “normalized” schema, in the sense that objects that are ostensibly the same appear only once: a distinct term will only ever appear once in the wp_terms table, keyed by its slug.

Here is where we get to the core of the above-stated problem:

Identical terms that appear in two different taxonomies are still the same term.

Yet, They are treated by the WordPress interface as if they are not.

This is because WordPress is doing everything it can to keep the terms/term_taxonomy tables normalized. If we have a term, “Job Market”, and it appears in both UK English Category and US English Category, then any changes to one will necessarily be made to the other, since they are sharing the same entry in wp_terms.

Why is this a problem? For me, it boils down to the following issues:

1. Terms in two different taxonomies are very rarely conceptually the same thing, even if they have the same text.
2. The WordPress administrative interface implies that a term in two or more taxonomies are NOT the same thing (they appear in different locations, after all.)
3. From a database engineering standpoint, it’s an extra, unnecessary table in the schema.

Why is it designed this way? As with many quirks in today’s software, it boils down to “legacy code.” WordPress grew organically over time, and certain decisions were made at the time in order to add features, that seemed reasonable at the time, given the problem being solved at the time, that did not fully predict future implications. WordPress was originally devised as blogging software, but is more and more being used for general CMS purposes. As a general-purpose CMS, complex taxonomy schemas such as the one we used for this recent project would be required for storing data into distinct buckets, which might have complex and overlapping domains. But suppose we could fix this? What could we do to address this issue, and maybe even simplify code and user experience in the process?

wp_taxonomy

The wp_taxonomy table is my proposed solution to this problem. It would consolidate all of the information in wp_terms with wp_term_taxonomy:

taxonomy_id
taxonomy
name
slug
description
parent
count
term_group

Notice that here there’s only two more fields in this table than in wp_term_taxonomy, one of which is the oh-so-mysterious-and-little-used term_group from wp_terms. Since linking to a separate terms table is no longer required, we can completely drop term_id, and then add the two relevant fields from the terms table, name and slug. Uniqueness on this table would then be enforced on the pair (taxonomy,slug). A schema like this would result in one less database table, one less field, and a lot more flexibility, since each taxonomy would now create a unique bucket of terms.

How much work would it take to adapt the API to use this proposed schema? It’s hard to say. A brief run-through of the functions that touch the database in wp-include/taxonomy.php shows that at least the following functions would need to be changed:

get_object_in_term()
WP_Tax_Query::get_sql()
WP_Tax_Query::transform_query()
get_term()
get_term_by()
get_terms()
term_exists()
wp_delete_object_term_relationships()  (Likely obviated entirely by proposed schema)
wp_delete_term()
wp_get_object_terms()
wp_insert_term()
wp_set_object_terms()
wp_unique_term_slug()
wp_update_term()
wp_update_term_count_now()
clean_term_cache()
_pad_term_counts()
_update_post_term_count()

This is most definitely not a complete list of all the functions that would require updating in order to work with this proposed schema. There are also all of the functions that hook into the various term-related actions and filters, as well as all of the back-end wp-admin code that would need modification. The above represents only the minimal set of core taxonomy API functions that would need updating, but I think it’s a good start.

If only it were so easy!

In an ideal world, where WordPress wasn’t already the beast that it has grown to be, with millions of sites depending on it, including many of the big players, (14.7% percent of the top million sites!) such a change might be a reasonable undertaking. But WordPress is a giant system with a huge community (some of which I’m sure will have something to say about my proposal!) and a monstrous ecosystem. While my proposed changes would (I believe) generally result in simpler code and a more predictable taxonomy system, it’s simply not feasible to make such a drastic change to core without a completely separate code fork.

As millions upon millions of sites are built upon WordPress these days, making dramatic changes to the database schema is a daunting task that would likely break thousands of sites, even if the API managed to stay the same. This is because there is still plenty of theme code out there that reaches directly into the two extant taxonomy data tables, and this would be the code that would most definitely be broken by any change. Perhaps a forked version of WordPress would be needed as a proof-of-concept, but even then, we’re looking at a development cycle that would span years to get such a major initiative off the ground.

You’re not alone. Visiting Drupal.org, the choice looks simple. Drupal 7. There are banners and buttons and headlines that all direct you to choose version 7 for your site. But wait – you were on a message board, or Google, or somewhere and saw someone mention version 8.

Well, why would you choose version 7 if 8 is right around the corner? Even the download page for Drupal 6 and 7 directs people to the Drupal 8 initiatives group page. Talk about confusing for anyone up against this decision.

The fact is, Drupal 8 is a long way off – at least 18 months, actually. Version 8 is in development, yes, but there’s a long road ahead before a release will be available for your web site. Drupal 7, which had it’s first release in January 2011, hasn’t even reached its adoption peak yet and that’s because of a number of reasons:

• Many of the contributed modules that are available for Drupal 6 still aren’t ready for Drupal 7
• The architecture changed in Drupal 7 and some functionality provided by contributed modules has been included in core Drupal. Some related modules may not work with Drupal 7.
• It is easier and more cost effective to develop for Drupal 6 because there are established development recipes for common feature requests
• Drupal 6 is still supported and works great
• Some argue there’s a steeper developer learning curve for Drupal 7 over Drupal 6

So, with Drupal 8 not even an option at this point (despite what rumors are floating around the internet), why on Earth would you choose an older version of Drupal?

For new sites, use Drupal 7

You should consider choosing Drupal 6 if there’s a key piece of functionality you need that isn’t available for Drupal 7, and it would cost more to build it than to use something already available for Drupal 6 (of course it’d be great if you could help port it to Drupal 7 and contribute it to the community!).

If you’re building your first Drupal site and you’ve already mapped out the site requirements and everything you need can be accomplished with Drupal 7, there’s no question – you should use Drupal 7. You’ll have the most up-to-date version of Drupal that is available and you won’t have to think about major upgrades for quite a while, probably years.

What it means to upgrade

If you have an existing Drupal 6 site and want to upgrade to Drupal 7, this part’s for you.

It’s important to know, up front, what you’re getting into when upgrading. Upgrading between major Drupal versions is more complicated than the incremental maintenance updates to modules and Drupal core that you probably already do. The underlying data structures change and in most cases there’s some development effort required to make your existing site’s theme compatible with the new version.

Depending on the level of customization on your existing site, this can take a long time. Not only that, but if some data doesn’t update smoothly it may need to be migrated by hand. Have a qualified development team do an assessment of your current site to determine how difficult an upgrade will be.

Does your current D6 site let you upload files or images using CCK’s filefield module? What about other fields like user references or node references? This is a great example of the difficulties inherent in major version changes. Unless you download and install CCK’s Drupal 7 dev branch, which you’ll later remove, to migrate this old field data to D7, you’ll have content with missing field data. Depending on what modules are enabled on your site, you may have to overcome these types of upgrade challenges for each of them.

Is it time for a new look?

If you’re already planning to update the look of your site, it could be the perfect opportunity to upgrade your Drupal 6 site to Drupal 7. Even if you’re not planning on adding new bells and whistles to your site, a redesign will require a new site theme to be developed. Depending on the complexity of your existing site it might make more sense to develop the new theme for Drupal 7’s framework instead of Drupal 6. Just check with your development team to make sure that all of your existing functionality will carry over after the upgrade.

Conclusion

New Drupal sites should be built with Drupal 7, unless a piece of custom functionality makes it cost prohibitive. Site owners wanting to upgrade from D6 to D7 in preparation for Drupal 8 might want to wait – Drupal 6 hasn’t gone stale quite yet. Finally, site owners that are ready for a design refresh should consider Drupal 7, but get an expert assessment to find out if it makes sense to upgrade.

Sometimes it’s easier to work with smaller files, whether it be for testing or importing small batches. I recently encountered that need, and my previous solution involved copying and pasting chunks of the XML WXR file from once place to another. This became impractical when I faced a nearly 200MB file that would cause my text editor to choke.

To address this, I developed the following set of shell scripts to work with these WXR files and break it into pages of posts in separate files. It requires an XSLT 2.0 processor. XSLT 2.0 is required because of the use of the xsl:result-document element. I used Saxonica’s Saxon Java class wrapper which provides a handy command-line interface to the Saxon libraries.

The xsl stylesheet

The goal of this stylesheet is to break apart the WXR file’s item elements (each of which represents a single WordPress post) into multiple files, while still preserving the WordPress meta data in each output file.

<?xml version="1.0" encoding="UTF-8" ?>
<xsl:stylesheet version="2.0"
		xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:param name="size" />
<xsl:param name="page" />
<xsl:param name="output" />

<xsl:template match="/rss">
	<xsl:result-document method="xml" href="{$output}_{$page * $size}-{($page + 1) * $size - 1}.xml">
			<rss version="2.0" xmlns:excerpt="http://wordpress.org/export/1.1/excerpt/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:wp="http://wordpress.org/export/1.1/">

			<channel>
				<xsl:for-each select="channel/*[local-name() != 'item']">
					<xsl:copy-of select="." />

				</xsl:for-each>

				<xsl:for-each select="channel/item">
					<xsl:if test="position() &lt; ($page + 1) * $size and position() &gt;= $page * $size">
						<xsl:copy-of select="." />
					</xsl:if>
				</xsl:for-each>
			</channel>
		</rss>
	</xsl:result-document>
</xsl:template> 

</xsl:stylesheet>

This stylesheet takes three parameters: page, the page number; size, the page size in number of “item” elements; and output, the prefix filename for the resuling output files. It will emit a file with the name $output_$start-$end.xml. You may note that this stylesheet can only handle one page of posts at a time due to the lack of for or while loops in the XSLT language (at least without language-paradigm-breaking hackery.) This also enables the output to be controlled fully from the calling program, which for this purpose will just be the shell.

Using the XSLT Stylesheet

The basic functionality of this stylesheet allows me to create a new WXR import file with a range of posts contained in the original. In this example, I’m copying the first 2,000 posts from the import file. After it completes, the posts will be saved into file_0-1999.xml.

$ java -Xmx512m -jar ~/saxonhe9-2-0-5j/saxon9he.jar -xsl:split.xsl articles.xml page=0 size=2000

I keep my Saxon JAR file in ~/saxonhe9-2-0-5j/saxon9he.jar, but you’ll likely have it somewhere else.

The -Xmx512m parameter tells the Java VM to set the maximum stack size to 512 MB. You may need to adjust this parameter according to the size of your input file.

Doin’ it all!

Now that we have the basic tool for pulling a single page out of our source XML file, we can use a little bit of shell scripting to get all of the posts into separate files.

#!/bin/bash

# filename: required
file=$1

# output file prefix: required
outfile=$2

if [ "$file" = "" ] || [ ! -f $file ] || [ "$outfile" = "" ]; then
   echo "Usage: $0 filename outfile [pagesize] [start] [limit]"
   exit 1
fi

# page size: defaults to 2000
[ "$3" != "" ] && pagesize=$3 || pagesize=2000

# start post: defaults to 0 (first post)
[ "$4" != "" ] && start=$4 || start=0

# limit: defaults to # of posts in input file
[ "$5" != "" ] && limit=$5 || limit=`grep '<item>' $file | wc -l`

echo "Splitting $file into" `echo "($limit-$start)/$pagesize" | bc` "pages of size $pagesize between posts $start and $limit";

i=$start

while [ "$i" -le "$limit" ]; do
	echo "Generating page $((i/pagesize)): posts $((i)) through $((i+pagesize))..";
	java -Xmx2000m -jar ~/saxonhe9-2-0-5j/saxon9he.jar -xsl:split.xsl $file page=$((i/pagesize)) size=$pagesize output=$outfile
	i=$((i+pagesize))
done

Save the above as split.sh, and the XSLT file as split.xsl in the same directory. Also, be sure to ensure the path to your Saxon JAR file is correct on line 29. Pulling this all together, we can take a large WXR input file and slice and dice it as we see fit:

[Meerkat ~/Oomph/]$ sh split.sh Articles.xml Articles 1500
Splitting Articles.xml into 16 pages of size 1500 between posts 0 and    24065
Generating page 0: posts 0 through 1500..
Generating page 1: posts 1500 through 3000..
Generating page 2: posts 3000 through 4500..
Generating page 3: posts 4500 through 6000..
Generating page 4: posts 6000 through 7500..
...

We now have 16 files of 1500 articles each, stored as

Articles_0-1499.xml
Articles_1500-2999.xml
Articles_3000-4499.xml

… And so forth.

Now you can import each of these files individually without choking your WordPress importer! I hope that some of you will find this useful. Keep in mind that the XSL stylesheet above could easily be adapted to work with other large XML data files, too. It would be just a matter of changing the element selectors that you wish to break apart.

The Editor window changes and updates just like the rest of WordPress, but has remained pretty consistent for the past few major versions. We’ll be sure to update this post with the newest tools as they are released.

First: Whizzy what?

WordPress uses a javascript plug in called TinyMCE for its WYSIWYG editor. WYSIWYG is an acronym for “What you see is what you get” and its the best way to craft content before saving your post. The editor is pretty powerful, with many buttons and options for writing content. Most of the options are familiar ideas, similar to options in a Word Processor – bold, italic, bulleted list style, etc… When designers like myself start to throw out terms like “H1″ and “blockquote”, though, most people’s eyes glaze over, but that is how these options are stored as HTML elements. Luckily, the Editor does the grunt work for you.

Second: Some definitions and pictures

The “WordPress Editor” window is the main focus of any page that produces content in the WordPress admin section. Most people are familiar with it for posts, and it looks like this:

A good theme will have some styles set up so that content in this window more closely resembles how it will look in your theme – colors, font, heading styles, etc… This helps you craft content that will look great before you even hit the “Save Draft” button and preview it.

No Kitchen Sink

When you fist use WordPress, the “kitchen sink” is off. So the Editor window will most likely look like this, with the following options:

The options explained:

Upload/Insert: This area is a container for all of the media options. Sometimes, plug-ins like the Next Gen Media gallery or Poll Daddy will insert an icon in this area for accessing shortcodes for those items. Clicking on any of these will usually open a modal window above the content for managing photos and the like.

Content View Switcher: The Editor window can function as a Visual Editor (WYSIWYG), or as an HTML editor for those more adventurous. This post will concentrate on options in the Visual Editor.

Bold: Highlighted text will become bold when this is clicked. In HTML, this uses a <strong> tag.

Italic: Highlighted text will become italic when this is clicked. In HTML, this uses the <em> tag. Can be used in combination with the bold button.

Strikethrough: Highlighted text will appear struck, with a line through the center.In HTML, this uses the <del> tag. Used to indicate text for deletion or removal, or to indicate that a change in the text has taken place.

Bulleted List: Highlighted text will be formatted like a bulleted list. Depending on your theme’s style, the bullets may be round or square. Lists can be nested – a bulleted list may have a numbered list inside of it. In HTML, this uses a set of <ul> and <li> tags for the “unordered list” and the “list items”.

Numbered List: Similar to above, but with numbers. In HTML, this uses the <ol> (ordered list) tag in combination with the <li> list item.

Blockquote: Highlighted text will be indicated as a blockquote, which typically means that a whole passage has been quoted form another source. The style of it will vary from theme to theme, but most of the time italic text is used, it is indented, and may have quotes around it automatically. The HTML element is <blockquote>.

Left, Center and Right Align: These buttons will align highlighted text. Most themes align text to the left by default and this is how an author can break out of that mold. An author need not highlight a whole paragraph, as this style will be applied from one full return to another. In HTML, since there are no native tags for alignment, TinyMCE adds a <p> tag around the paragraph with a “style=align: right;” applied to it.

Link (chain icon): The link icon is available for clicking only when text is highlighted. Highlighting text and clicking this button will open a small modal window where an author can enter in the destination URL, choose whether or not to open in a new window, or choose to link to another page on their own site. In HTML, the tag used is <a href=”http://example.com”>Link Text</a>.

Unlink (broken chain): To remove a link, an author can highlight the whole link or simply place the cursor within the link and click this button.

The “More” break: WordPress has an option of adding this physical break to the post – breaking it into two sections, the teaser and the body. If your theme displays the entire post by default on category landing pages, the “more” break is a way to show only some of the content, forcing users to click a “Read More” link to see the rest of the body of the post. Upon clicking the “Read More” link, the user will be brought directly to an anchor in the text where the post continues, so they do not have to read the same teaser again.

If your theme’s landing pages use excerpts instead, this “more” break may not have the intended effect.

Spell Check: This button is a drop down that will change the preferred language of the editor’s spell check dictionary.

Full Screen: Toggles a full screen view of the editor so authors can concentrate on composing their post. Useful, but the buttons for styling your post will be limited in this view to bold, italic, bullets, numbers, blockquote, insert media, insert link, unlink and help. Learn the “Hotkeys” to access more style options (see the Help modal window for a list of Hotkeys and how to use them).

And finally, Toggle Kitchen Sink: This button simply makes another row of options available for styling your post. Those options are explained next.

Kitchen Sink!

With the kitchen sink option on (and WordPress remembers if you prefer it on), a whole slew of additional options are present.

Style drop down: (graphic below) Within this drop down are styles intended for block-level elements – paragraph, address, preformatted, heading 1, heading 2, etc…

The best way to think about inline vs. block-level may be this: A bold tag is inline, because you can bold a portion of a sentence; A Heading 1 is block-level because it will effect all the text in a block, from one hard return to another.

Underline: Highlighted text will have an underline applied to it. In HTML, the tag is <ins> (for insert). Your theme may apply an underline to links, so be sure to use this tag when appropriate, and don’t fool your readers into thinking something might be clickable when it is not.

Justify: Another alignment option. This one is by itself because authors should use it carefully. Not all browsers support the justify feature, and since browsers do not hyphenate text, this style may create “holes” in your paragraphs when spacing between words need to be very large.

Text color: Highlighted text will turn a variety of colors by using this button. When clicked, a standard palette of colors will appear for you to choose from, and a limitless palette is shown when the “More Colors” option is clicked.

Paste as Text: THIS BUTTON IS AWESOME! Very useful for authors who cut and paste text from other sources. Ever copy text from another website, and all the styles come with it? Soon you have a mish mash of styles in your post. You can get frustrated scraping the style tags in HTML view, or you can paste with this button to begin with. When clicked, a new modal pops up with its own text area. Text pasted into this area is converted to “plain text”… nothing but the facts, ma’am. This allows for much easier styling and integration into your content.

Paste from Word: THIS BUTTON IS ALSO AWESOME! Ever cut and paste content from Microsoft Word, and all the sudden your post looks funny? That’s because a bunch of styles – and, frankly, gobbledy gook – comes along with the content from Word. To paste the text in as plain text, click this button and paste your content into that window first. This option is better if you know the content is coming from Word than the Paste as Text button, as it specifically removes tags that Microsoft Word generates.

Remove Formatting: Highlighted text will have styles removed. While this icon is an eraser, it must be noted that it does not always remove every style. It does a better job removing styles that the editor has added in already. It does not consistently remove styles from text that has been cut and pasted from other sources.

Insert Special: This drop down list helps to insert special characters that are hard to access unless you know the special keystrokes.

Remove / Add Indent: A highlighted block-level element will be indented or un-indented with these buttons. Since there is no HTML element for this, TinyMCE adds a “style= margin-left: 30px” to the element. 30px is the default indent increment.

Redo / Undo: Simply keeps track of changes and allows the author to undo or redo a set of changes. I’m honestly not sure how many changes it will keep in memory before they get lost.

Help: A simple modal with Basic and Advanced tips will pop up when this is clicked. The most interesting to me is the table of “Hotkeys” available to authors. Did you know command 1 will make a selection take on the Heading 1 style?

And one more

The last thing I want to review is the contents of the Style drop down.

As briefly mentioned before, the style drop down menu contains a bunch of standard block-level elements. This means that a whole paragraph will get the style, not just a selection of portion of a paragraph. The styles are:

Paragraph: Used by default, but useful if you have chosen another style but want to switch it back to the default paragraph style In HTML, this is the <p>…</p> set of tags.

Address: An interesting tag, address is usually italic for some reason. I wonder if blocks using this tag have special weight with search engines, but very little data is available to back up that hunch. Personally, I rarely use it.

Preformatted: The <pre> tag is a tough cookie. It is intended to display text with white-space preserved, meaning that breaks in the text will be exactly as written. To me, this means trouble, as if there are no breaks in the text inside of this tag, then there are no breaks on the front-end as well, and that can lead to some goofy looking posts. A good theme will take into account the intention of a <pre> tag, but ensure that the display will not break the layout. Again, rarely used… most people use it to display chunks of code.

Heading 1, 2, 3, etc… These are great and every author needs to know how to use them. The concept is simple – headline styles, with more size or boldness given to the lower numbers. But search engines use these tags to determine where the important phrases are in the content as well (and in the page in general) so they should be used not only because they help organize your story, but because they also give your content extra weight.

That’s all folks!

Thanks for reading, and I hope this helps. There is a lot of options packed into this little Editor window, so take advantage of the array of style options WordPress gives the author. Happy blogging!

I recently had to create some templates for Constant Contact and I thought, “Hey, this should be easy. Can’t do anything tricky, so, keep the design simple, use a tried-and-true table for the layout, and viola, beautiful emails”. While you can’t do anything tricky, it’s true, there is so much more to consider, and it’s all pretty annoying if you are used to designing for the web. I enjoy designing for IE6 slightly better than designing email templates.

With that frustration in mind, here are some tips I ran across that might be useful for you, but will be very useful for me as I know I will forget them all just in time to design a new set of templates:

Design Specifically – Everything needs a class

The most annoying aspect of Constant Contact for a web designer who liked their code to be clean and nested is the fact that IDs are NOT supported, and neither are styles on HTML elements. So, the CSS selector body p is a no-no. Not even a rule that uses an explicit h1. Instead, you must define a .header1 class and apply it to an h1, like this: <h1 class="header1">.

Ridiculous? Maybe… but here’s why. When Constant Contact assembles your email, it takes all these rules and spells them out explicitly right in the element. So while you may define a normal style, it uses it as a reference and spits out an inline style tag on the element itself. So this:

.header1 { font-weight: bold; font-size: 20px; color: #333333; } <h1 class="header1">A Sample Header</h1>

Becomes:

<h1 size="20" color="#333333" style="font-weight: bold; font-size: 20px; color: #333333;">A Sample Header</h1>

It does this so it can cover the widest array of email clients out there. And it would be maddening for us to try and code this way with all those inline styles. So while the idea of using a stylesheet is like the web, the way Constant Contact uses the stylesheet is not like the web at all.

Design like it’s 1993

We all know KISS, but when I say simple, I mean REAL simple… 1993, beginnings-of-the-internet simple. Take the <center> tag, for example. The good ole margin: 0 auto; won’t work consistently enough, so break out the dusty <center> tag instead.

Use tables for layout. I know, I know, that’s SO 1993, but I’m serious… trying to consistently float divs and clear floats will drive you mad.

Also, forget bit-saving CSS shorthand. You’re better off using the full six-character hex values for colors when you normally might use three. Four values for padding and margin seems to be well supported, but use the long-form tags for font-size, font-weight, font-family, and background properties. Actually, forget background images all together. Many email clients won’t load them.

When using images, style the container like its text

This one may not be very intuitive, but let me explain. I’ve got an image, and it’s important – it’s the logo. I know some email clients won’t load the image by default (looking at you, Gmail), so when the image doesn’t load, I want the contents of the alt tag to display instead, and I want it to look good.

To do this, I simply made sure the container that the image is placed inside has some fallback styles for text. So while the alt text disappears when the image loads, if the user never loads the image, it still looks nice and we don’t lose important information, like the name of the company. Here’s what I’m talking about:

Before images load...

With images loaded.

Use Anchor (Jump) links Carefully

This one particularly bugged me, and took a little time to figure out. The client wanted a Table of Contents with simple anchor links to make the email jump down to the proper element. I knew that support for hrefs that jump down to an element with an ID would be spotty, but a simple <a name="anchor"> would work, right?

Silly me, what was I thinking?

Besides the fact that even these basic elements have spotty support (see this article from Campaign Monitor), there is also a problem of styling and the way Constant Contact handles empty HTML elements.

In order to appease the greatest number of email clients, my code for anchors links was <a name="anchorname" id="anchorname"></a>. But there was a simple problem with that. Since it was empty, Constant Contact turned it into a self-closing xHTML element, which looks like this in the source of the email: <a name="anchorname" id="anchorname" />. The problem is, most email clients won’t recognize an anchor tag that self-closes, so my email had open anchors everywhere, which turned my text default link blue.

The solution is god-awful, and I would never allow my web pages to look like this, but this is what I had to do for it to work and look good. I had to add a style class to handle these links, because even though there is no HREF declaration, email clients will still treat it like a link and turn it default link blue. :

<h3 class="header3"><a name="anchorname" id="anchorname" class="anchor">Headline Text</a></h3>

Send us Your Tricks!

Designing emails is frustrating enough… and this list is by no means exhaustive. What issues have you encountered? Send them over here and we’ll keep them compiled for you!

In Conclusion

I hope you never have to design email templates, because they really can be frustrating. All the efficiencies you’ve learned while designing for the web get thrown out the window. Still, email is an effective (and cost effective) form of communication, so it won’t go away. It can only get easier as older mail browsers are slowly phased out, but the fight to eradicate IE6 is nothing compared to the fight to eradicate Outlook (Outlook has no support for simple styles like padding and float).

In short, stay sane, stay calm, and use Google to help you figure out the baffling problems of designing email templates. Keep the design simple and the message short.

And good luck… you’ll need it.

For the second year in a row, our very own Erick Hitter has been working hard behind the scenes as one of the core organizers, contributing to the event website and pulling together a top-notch list of corporate sponsors. We’re proud to say that we made Erick’s job a little easier this year by getting Oomph on the corporate sponsor list.

I am also very excited to be speaking this year. At 3:30 on Saturday I’ll be leading a talk on the WordPress VIP platform:

Enterprise Publishing on WordPress.com VIP

Whether you are considering a migration to WordPress, exploring a switch to enterprise-level hosting, or just curious to learn more about what this VIP thing is all about, this talk should be a valuable resource.

Please stop by and say hi and keep an eye out for other attendees from the Oomph team.