graphicpush

• Home
• Archive
• Books
• Templates
• Icons

Part of the 9rules network.

The Power of Custom Fields in TXP

Now that Textpattern has reached a stable, usable, well-tested version, I have been deploying it on more client sites than ever. Oddly enough, these sites have all been of the straight content variety—no blogs.

Travel With Your Kids is my most recent project gone live, and features my most complex TXP install yet, with nested categories and sections, customized ad positioning for every page, plus heavy use of custom fields.

Earlier versions of the software used to bury custom fields outside the backend GUI, but version 4 brought them into the admin user interface, making them an easy way of extending the CMS’s capabilities. TWYK utilizes custom fields in three important ways:

• Content fields
• Controlling the order of displayed articles
• Template triggers

Content Fields

I imagine that custom fields were originally designed by Dean and company as a means of extending the number of content inputs, and they work beautifully doing so. Two custom fields for meta information have their content displayed with each article.

<title>
   <txp:if_custom_field name="meta_title">
      <txp:custom_field name="meta_title" />
   <txp:else />
      <txp:section title="1" />: <txp:title />
   </txp:if_custom_field>
</title>

There is a custom field for the article title because the client requested this be manually controlled in case the title of the page should be different from the title of the article. (It’s an SEO thing.) The conditional script checks to see if the custom field “meta_title” is populated. If it is, we publish the contents; if not, we fall back to the section name followed by the default article title.

<meta name="description"
content="<txp:custom_field name="meta_desc" />" />

The custom field “meta_desc” is always populated (unlike “meta_title”), so we don’t have to use a if_custom_field tag to check for content.

<meta name="keywords" content="<txp:keywords />" />

Finally, the keywords meta, which pulls its data right from the “keywords” field in the article admin area. In my previous article about meta in Textpattern, I advocated using a custom field for the keywords, but since then the development team has allowed the default keywords field to be output.

Using custom fields for extra content is a no-brainer; graphicPUSH uses six for miscellaneous content stuff beyond meta output. In my book reviews, there is a custom field for each of the “book information” entries.

Using Custom Fields to Order Articles

When creating a non-blog CMS, the date of creation for the articles is mostly irrelevant, so it’s not logical to order articles from when they were posted. At the same time, sorting alphabetically doesn’t make much sense either.

Thankfully, Textpattern gives us a host of sorting options in the article tag, including the capability to sort by custom fields. For Travel With Your Kids, a category like Hong Kong needed to have the order of the articles tightly controlled. So I created a custom field called “custom_3,” and within the template, placed this:

<ul>
   <txp:article limit="999" sortby="custom_3" 
      sortdir="asc" form="listlink" />
</ul>

Inside each article, “custom_3” has a number entered, like 05, 07, 21 or 98 or whatever. These numbers represent the order of appearance of the articles when output in the list, so “01” would be first. (You could also use letters, like A-B-C, but that seems less intuitive.) If you decide to use this technique, here are two important tips:

1. The custom field must have a default name like “custom_3” or “custom_7.” TXP/MySQL does not recognize custom field names beyond this, so you can’t call your custom field “pageorder” or something. I guess this is a bug. If Microsoft wrote this software, it would probably be called a “security feature.”
2. You have to number your articles alphabetically, like file names on your OS. If you count from 1 to 12, your articles will go in this order: 1,10,11,12,2,3,4,5,6,7,8,9. To circumvent this, add a zero before single digit integers, like 01,02,03,04, etc.

Using Custom Fields as Template Triggers

This is where the real power comes in. The Textpattern wiki entry for if_custom_field hints at the capabilities with the last example, but TWYK needed some more advanced template switching. Let me explain.

Each section has its own page in Textpattern. So the “Destinations” section runs off a page called “destinations,” the “Before You Go” has a page called “beforeyougo,” etc. Each of these pages must display three things: the section landing page (/destinations), the category landing page (/destinations/?c=Grand-Canyon) and finally individual article pages (/destinations/grand-canyon-where-to-stay). Here is the code:

<txp:if_category>
   <txp:article form="article_sticky_category"
       status="sticky" />
   <txp:article form="singlecategorypage" />
<txp:else />
   <txp:if_section name="destinations">
      <txp:article form="article_sticky_section"
         status="sticky" sortdir="asc" limit="1" />
   </txp:if_section>
</txp:if_category>
<txp:if_individual_article>
   <txp:article form="article_full" />
</txp:if_individual_article>

Here is the logic for the first three lines: If it’s a category landing page, show either the “sticky” article of the category if the category has multiple articles, or show the single “live” article in that category if that category has only one article. (A multi-article category will always have a “sticky” article to serve as a landing page, and a category with only one article will never have a “sticky” article because the single article will serve as the landing page. Whew.)

An example of a multi-article category: The Grand Canyon.
An example of a single-article category: Genova.

The trick is that a category with only a single article must have its page look like any full article in any other section, not like a “sticky” article landing page, so we need a means of telling Textpattern when a category only has one article. How? Custom fields.

I created a custom field called “singlepage.” For most articles, it is blank so it triggers nothing. For the Genova article, I entered “yes” in the field. You’ll notice there is a article form called “singlecategorypage.” Here is what that form looks like:

<txp:if_custom_field name="singlepage" val="yes"> 
<txp:body />
.... other stuff ....
</txp:if_custom_field>

This article form is going to be completely ignored 99.9% of the time because almost no articles have “yes” placed in the custom field “singlepage.” However, for those that do, it essentially tells TXP that there is no “sticky” article for the category and there are no further articles within that category.

Beyond This Article

I am sure there are uses for custom fields beyond the scope of this article, but these are just three uses for one project. While TXP allows for a lot of customization and flexibility, custom fields take that power and double it. By using them as template triggers or even simple content fields, it makes TXP all the more suited for professional deployment.

Comments.

Metadata.

Copyright 2008 Kevin Potts | Contact | Advertise | Subscribe | Hosted With Dreamhost