We begin today’s sermon with a word from Bert Mahoney, aka Berchman, WordPress developer/designer and member of the Thesis cognoscenti:

Bert is being rather blunt. He’s allowed, because he’s right. A backup strategy can spell the difference between success and failure in your web ventures. It can turn data loss disaster into momentary inconvenience. And yet, the number of people who cannot be bothered to back up their web installations – people, mind you, who have pinned their identities, hobbies, and livelihoods to their websites – is so high as to astonish.

The brief for backing up

There are many variables involved in installation and configuration – obscure server settings, potential plugin conflicts, customizations to style or function – that it’s impossible to anticipate everything that might go awry during an upgrade to a site. These are not reasons to be afraid; rather, they should prompt us to prepare. A complete backup strategy allows users to proceed with upgrades without fear.

There are some Thesis users who believe that dealing with unexpected results of an upgrade is as easy as switching back to a previous version of the theme. This is not the case, because Thesis is not your grandfather’s WordPress theme. The dynamic nature of Thesis and its relationship with the site database means that ‘rolling back’ to a previous version can be problematic: the result can be multiple and conflicting sets of settings in the database. Customizations be confused or lost. I’ve seen it often enough, and it’s a shame: a prudent backup would have spared these folks a great deal of angst.

Let’s put it this way: The makers of WordPress itself advise you to backup before starting its famed and usually smooth automatic upgrade. Are you smarter than the makers of WordPress? With due respect, I think the answer is ‘probably not.’

No one is (or should be) more responsible for the safekeeping of your site and its content than you, the site owner. So: let’s talk about being responsible.

What to backup

Many site owners believe that backing up consists solely of downloading web files to their local computer. Your site’s files are important, but they are only half the story. Think of your web installation – your WordPress files and folders, your Thesis files and folders, your various plugins and fonts and scripts – as the corpus of your site, its physical body. There’s much more to your website than that. There is also the database, the soul of your site: every post, every comment and link and custom field, each and every setting. Web files and database, and each are crucial. Without files, the database is a mere airy ghost, ineffectual, insubstantial. Without the database, your web files make up an inert thing at best…or at worst, a shambling, soulless creature mindlessly repeating a single word: Braaains…braaains…

No backup can be considered complete unless it involves both database and web files.

Example: How ThesisLab backs up

This site resides on a shared hosting account at the excellent Steadfast Networks, which provides me with a control panel called H-Sphere. With this tool, I can easily initiate a backup of both my site’s web files (called a domain by H-Sphere) and its database. Once the backup process is complete, I download the files to my local computer. I keep the set of two files together – domain and database – for any given backup date. I back up twice a week – and before any major upgrade – and I retain at least three weeks’ worth of backups. Additionally, I keep my backups in two different locations: on my local computer and on an online storage service (an Amazon S3 account). If the need for restoring my site through backup arises, H-Sphere provides an easy

So: I don’t spend a lot of time worrying about upgrades, because I know I really can ‘roll back’ to a previous state of the site at any time.

Backing up with cPanel

It is beyond the scope of this blog post to cover every kind of backup approach possible. However, I will spend time on backing up via the popular administration tool cPanel.

You start by opening the Backup Wizard, where you are given the choice of performing a backup or a restore.

Choose Backup. You’ll then see several different kinds of backup which you can perform.

Full backup (on the left) backs up all files and configurations in your site. It’s great to have if you want to move your site from one host to another (assuming that your new host also uses cPanel), but know that you cannot restore a full backup yourself. Only your webhost can restore your site using a full backup file.

For regular backup purposes, our topic of today, the following two options (on the right) are best:

Home directory, which contains such folders as public_ftp, public_html (which contains all of your web files, including WordPress and Thesis), mail, and others. These are your site’s web files.

MySQL databases, which is where all of your WordPress settings (including all posts, comments, categories, tags, custom fields, etc) and Thesis option panel settings are stored. This is your site’s database.

Clicking home directory will take you to a page where you can begin the download of your home directory to your local computer. Clicking MySQL databases will take you to a list of all your website databases. Both your home directory and your site’s database will be compressed before bring downloaded; even so, home directories can take a while to download. Do not leave your backups on your server.

Other backup notes

I have never backed up in the GoDaddy hosting environment. GoDaddy users should browse this collection of articles on backing up their sites. It’s good advice in general to search your host’s help files or knowledgebase to learn how to use the particular tools the host makes available to its clients.

Some users may be interested in the VaultPress backup service made availavle by Automattic, makers of WordPress.

If your hosting account provides you with phpMyAdmin and you’re familiar with its use, backing up and restoring the database at least is fairly straightforward. You’ll still need to find a way to back up your web files, however.

If your host doesn’t provide you with tools to back up either your web files or your database, it is well past time for you to find a new host.

In conclusion

I hope you away from this post not intimidated by things that can go wrong with an upgrade, but rather that you leave feeling empowered to protect the work that you’ve put into your online efforts. It’s your responsibility, after all.

Holders of the Developers Option for Thesis may be interested to know that Thesis 1.8 beta 2 was released last night. Per theme author Chris Pearson:

What’s new in beta 2? Custom loop API, favicon uploader, security enhancements, and new fonts, including the entire Google Font Directory!

The usual caveats about running beta programs on production sites still hold, but that will stop neither the prepared nor the impetuous. Holders of the Personal Option who want to upgrade to the Developers Option in order to try the new beta are welcome to upgrade though the ThesisLab affiliate link.

Brief note: The DIYthemes site and support forums are up and running once again.

You may have experienced problems accessing the DIYthemes site over the weekend, including the support forums; this is the result of a hack attack. Thesis architect Chris Pearson and others are working on the situation, and it’s my belief that things will be sorted in due course. I imagine that Chris will make any relevant announcements via his Twitter account @pearsonified.

For Thesis users who have not kept an ear tuned to Twitter today, Chris Pearson announced there the release of the first beta version of Thesis 1.8. This release, like all beta versions of the theme, is available only to holders of the Developers Option. As an affiliate of DIYthemes, I am practically obliged to mention that anyone anxious to lay hands on version 1.8b1 is encouraged to purchase the Developers Option to Thesis (or the upgrade from the Personal Option to the Dev Option) through the Buy Thesis page here. (This includes one free installation of Thesis on a self-hosted WordPress site, courtesy of ThesisLab.)

Note, however, that ThesisLab is still running on version 1.7 and will continue to do so until 1.8 goes gold. That’s not because of any fear that 1.8 will cause the site to explode. Rather, it’s simply common sense. The ‘b’ in 1.8b1 stands for ‘beta,’ and ‘beta’ means ‘not yet declared stable.’ Running a production site on a platform not yet determined to be stable is reckless and foolhardy, and cannot be excused by any amount of enthusiasm for something new and shiny. I am currently running 1.8b1 on a test installation. It is performing well, and the new features are appealing. Anyone who reads this and decides to give the new beta a try is welcomed to do so, as I am doing, on a test install.

I’ll post info on my experiences with all beta versions of 1.8 as it moves towards the final version. Once 1.8-final is released, I’ll update the installation guide here to reflect the new version.

PS – I’ll mention just this one this improvement for now: The file layout.css, which many Thesis users have been editing with abandon even though they certainly shouldn’t, is no longer available for editing in the Custom File Editor. Huzzah! That’s worth an upgrade all by itself.

Thesis 1.7 introduced the means to set title, meta, and JavaScript information for category and tag pages. This was done in the name of achieving fine-grained control over search engine optimization. As with categories, a list of all tags appears in the Thesis Page Options panel along with fields for entering your information and making JavaScript selections. A certain amount of processing is done as Thesis accounts for your categories and tags when you save settings. For Thesis users with many, many tags – hundreds or thousands – assigned to their posts, this processing may take so long that an ‘unresponsive script’ error message may result, and your option panel may ‘hang.’

Solutions for this situation are being investigated. Until a fix is made available, I have devised a simple workaround that will enable Thesis users to sidestep the issue by removing the Tag Page Options module from the Thesis Page Options panel. That workaround is posted at the DIYthemes forums; Thesis users, duly registered at the forums, will be able to log in following the above link and access the info.

Site traffic reports indicate that some visitors to ThesisLab who use the theme’s built-in Custom File Editor have sought an answer to error messages that look something like this:

Fatal error: Call to undefined function use_codepress() in /ANY_OLD_DIRECTORY/public_html/wp-content/themes/thesis_XX/lib/admin/admin.php on line XX

In most cases, the answer is that your version of WordPress is too old. The Codepress function was included in WordPress as of version 2.8; an older version of WP won’t have it, and any call for it will go unanswered (as in ‘undefined function’). The answer then, would be to upgrade WordPress and you’d be good to go.

However: Thesis users who are adventurous early adopters of WordPress 3.0 beta are running into the same kind of error message when they attempt to use the Custom File Editor. The reason in this instance is that the use_codepress function is now deprecated in WordPress 3.0, and the reason for that is that the 3.0 download badly needed to go on a diet. Some things had to get the axe, and CodePress was first or second on the list.

What does this mean? Let’s start with what it doesn’t mean: It doesn’t mean that the Custom File Editor is unusable under WP 3.0. The editor itself works fine. What you won’t be able to do, however, is to use syntax highlighting. There is a line in the Thesis core file admin.php which calls for syntax highlighting using CodePress, but since that is no longer available in WP 3.0, the call goes unanswered and the editor gets borked.

So until Thesis architect Chris Pearson and the DIYthemes crew devise a new approach for highlighting (and I have every confidence that they will), here’s a temporary workaround:

Use your FTP program and your favorite plain text editor to navigate to and open admin.php (the path is thesis_17 (or thesis_16, if you’re using that version)/lib/admin/admin.php).

Comment out the line that calls for syntax highlighting by placing two forward slashes just before it. Example:

// if (use_codepress()) add_action('admin_print_footer_scripts', 'codepress_footer_js');

The line number at the end of the error message will tell you which line to comment out in admin.php. If you’re running Thesis 1.7, that should be line 46 42 (thanks, Greg); if you’re using Thesis 1.6.x, that should be line 57.

This should keep you rolling until a permanent solution is released.

Update, July 7:

ThesisLab – that would be me – cheerfully announces an upgrade to the Cutline Plus style for Thesis! The upgrade consists of two minor fixes and one fairly major improvement. Here’s the info on the fixes:

• It was reported that the banner image occasionally protruded beyond the right margin in IE. DIYthemes forum member milamber volunteered an overflow:hidden addition to .custom #header_img that quickly fixed it.
• DIYthemes forum member vonaras reported that navigation menu tabs for categories lacked the styling that has been assigned to pages. That was a simple oversight of mine – I had forgotten to test for categories earlier – and it has been remedied.

The big news, however, concerns a change to the way that users had to manually select (in custom_functions.php) the right source folder for banner images when setting the number of columns for a Cutline Plus site. The change: users don’t have to do that anymore! That’s thanks to a two-step process in custom_functions.php:

1. Particular CSS classes – named three-columns, two-columns, or one-column – are now assigned to the body of the site depending on the number of columns chosen for the layout.
2. Based on the body class in use, a function automatically calls banner images from the appropriate source folder: headers3_col, headers2_col, or header1_col.

I’m very happy to provide this enhancement for users. Anyone who has downloaded Cutline Plus in the past is invited to upgrade immediately!

I have noted the rising incidence of reports that go something like this:

I edited layout.css to add customizations to my Thesis site, but after saving settings in the options panels, everything reverted to default! I’ve tried this [X number of] times and the same thing happens. ‘Sup with that? Is this some kind of bug?

First, the answer: No, this is not a bug. Rather, this is a consequence of the way that layout.css works in Thesis. The content of this file is a reflection of database settings made via the Design Options panel. Settings flow from the options panels-slash-database to layout.css, not the other way around. Any manual edits made to layout.css will be overwritten the very next time you click the big green save button in Design Options.

Fun/stupid layout.css trick: Access that file via FTP. Open it in a plain text editor. Delete all of its content. Save the file. Visit your WordPress admin and go to Design Options. Click the green save button. Use your FTP program to go back to layout.css and open it with your text editor and – hey presto! – all of the file’s content is back. This is, again, because (say it with me):

Settings flow from the options panels-slash-database to layout.css, not the other way around.

This is why custom style rules should instead be placed in custom.css, which by design does not get overwritten.

Now, the context: I believe that the rising incidence of users trying to directly edit layout.css is a result of that file having been moved into the custom folder (as of version 1.6). The file now shows up in the Custom File Editor, and so people, well, quite naturally try to edit it.

As I said above, however, they should definitely not.

Over the past couple of weeks, a number of people asked me about a reported new feature in Thesis 1.7, the headline filter, which would allow users to get rid of headlines without resorting to untidy methods like display:none. Where was this filter? How to use it? All I could do in response was smile and wave.

Since then, however, I’ve had a chance to snoop around inside 1.7, and to see (in a DIYthemes forum post by moderator Girlie) an example of implementation of this filter, the full name of which is thesis_show_headline_area. It is called in thesis_headline_area, which you can find if you go looking through your thesis_17/lib/functions/content.php. The filter is a binary proposition; you’re either shown the entry’s headline (true, which is the default state) or you’re not (false, which is the value you must use in the function to make your headline vanish).

Let’s take a look at that example of a function making use of this filter. The function is whimsically titled pwn_headline. The function says that if the post is in the category ‘asides’ (a popular term for posts that, because of brevity or topic, may not warrant a headline), it will return a value of false – which means that the headline will not show.

function pwn_headline() {
if (in_category('asides'))
return false;
else
return true;
}
add_filter('thesis_show_headline_area', 'pwn_headline');

If you’ve worked with functions before, you’ll recognize in_category as being an example of a conditional tag (as in, the post is in a certain category). Using different conditional tags, you can apply the headline filter in a variety of situations: to posts in other categories or tags, to content on specific pages or on all pages, any circumstance than can be expressed in a conditional. I’m sure that smart folks will find many ways to expand on use of this filter.

Note 1: If you would like to filter out headlines for more than one category, you’ll want to use an array in your function. Here’s a variation on the above example which shows an array of categories in action:

function pwn_headline() {
if (in_category( array('asides','twittered','shared') ))
return false;
else
return true;
}
add_filter('thesis_show_headline_area', 'pwn_headline');

The same general arrangement applies for filtering out headlines for more than one static page; again, you’ll want to use an array as below:

function headless() {
if (is_page(array(42,'about-me','About Me And Joe') ))
return false;
else
return true;
}
add_filter('thesis_show_headline_area', 'headless');

In the page array example above, you can see that you should be able to use the ID number of the page, page slug, or the actual page title. (Thanks to AJ for suggesting I add the page array example.)

Note 2: As indicated by the name of the filter – thesis_show_headline_area – more than just the headline is affected by changes caused through the filter. The headline_area also contains the headline_meta: byline information which may contain the author’s name, the date of the entry’s publication, the number of comments on the post, as well as the entry’s category and tag. Using the headline filter to get rid of an entry’s headline will also wish the rest of that information into the cornfield. Here is an example, On my personal blog, I avoid losing that byline information when the headline is filtered out because I had previously moved the byline out of headline_area altogether, based on the technique laid out in the DIYthemes Answers blog.

Addendum: Step-by-step

For anyone still out at sea on the headline filter, here’s a very basic walkthrough.

First, name the function. It can have any name that has meaning to you. You will need to repeat it exactly in the last line of your code.

function name_of_function() {

Choose the conditional tag that defines the condition under which you want the headline to not appear. For example, if you want the headline to not appear on your About page, you will use the tag below, and you will list the name of the page.

if (is_page('About'))

The next section says that for the condition you just defined, the headline will not appear. It also says that under conditions other than the one you just defined, the headline will appear.

return false;
else
return true;
}

Finally, the add_filter statement will show which filter is used (the full name of the headline filter, which is thesis_show_headline_area) and which function applies to it (the name of your function, from the first line).

add_filter('thesis_show_headline_area', 'name_of_function');

So all together, this would be the function to add to custom_functions.php to eliminate the headline on your About page:

function name_of_function() {
if (is_page('About'))
return false;
else
return true;
}
add_filter('thesis_show_headline_area', 'name_of_function');