I got an email from Eric yesterday asking if I would share how I created the A-Z index on the Humboldt State University site with Textpattern. His email was timely, because with the new TXP 4.0 release, I was planning on re-examining how I did the A-Z index (which was done in one of the gamma releases) to see if it could be cleaned up a bit. I thought I’d publish this here as well, in case anyone else is interested.
The index I inherited from the previous webmaster was just 26 static html files that needed to be maintained and alphabetized by hand. The textpattern solution is probably not the cleanest database solution that I could have set up, but it was one I could wrap my head around, and gave me several other benefits of Textpattern. These include the ability to set up an easy-to use interface for student assistants, and keep track of which author had published something to the index.
There are 3 components to the index:
- the links to the index sections which fall along the bottom of the main page, which are managed through the textpattern link functions,
- the data, which are stored in custom fields of textpattern articles, and
- the display of the data, which is done through a page template and forms.
If these terms don’t make sense to you, you may want to check out the Textbook entry on the semantic model of textpattern.
For the links, I set up a category of TXP links called
azindex, and set up 26 links in this category (one for each letter of the alphabet). The name of the link is A, B, C, etc, and the url is
/siteindex?c=B, etc. The
?c= in the url tells textpattern to only display articles assigned to the category indicated.
On the main page I output the links for the index with
. I output these as an unordered list, and use CSS to style them as a horizontal bar across the bottom of the page. This step could probably be skipped and the links just added directly to the code of the page. I did it this way to make my page templates cleaner— 26 links adds a lot of code!
For the data, I set up 26 article categories, one for each letter of the alphabet, and a section called
siteindex where I would display the results when one of the index links is clicked.
I use the article custom fields to hold the index information. I have 5 fields set up, which correspond to the information in the index: Department Name, Department URL, Location, Phone, and Fax. When I enter a new item, I fill out these fields and the title only, leaving the body blank. I also categorize each entry under the correct letter of the alphabet, so TXP know which A-Z index page it corresponds to, and make sure I post it to the section
To display the index results, on the
siteindex page, I set up a table and headers for the output (which is tabular data), and then call the relevant results with
. This uses the
chh_article_custom plugin, which allows me to sort the the results by title, rather than in the order they were posted. (So index items can be added in any order, and I can be sure they end up alphabetized). This option wasn’t available for
in the gamma releases, but it is there in v4.0, so you don’t need the plugin anymore.
Finally, in the form
azlist1, I use the
rei_show_custom plugin to output the info in the custom fields. Here is what the form contains:
In 4.0, this can now be done using the
tag, and there is no need for the plugin.
If I need to use an alternate format for the display of a particular entry, I use an override form to do this. My main override form has
which I use when I need to say something like: Information Technology Services: see also Academic Computing, Telecommunications & Network Services, Instructional Media Services, or University Computing Services. (See this example live here.)
Once all this is set up, all you have to do is input all the articles. Student assistants are good for this (thanks Kent!).
Inputting the articles was a big initial investment for
me , but maintenance of the A-Z index is a breeze now that it is set up. And it is heavily used— most of the on-campus folks at the University use the A-Z Index to find their sites they need, rather than traversing the navigation hierarchy. It has proved a good solution for us, in the absence of a university-wide LDAP database or other system we could have tapped into.