Solution: Not exactly sure, but it seems to have stopped.

There are several WordPress posts that go over an issue of using the

[/sourcecode]

tag to write sourcecode.

Personally, I was very frustrated because while writing in Python, where whitespace matters, my indents would all be lost when switching between the visual and HTML editor in WordPress.

My solution was to wrap my

[sourcecode]

tags in <pre> tags.

Check the plugin?

I originally was using the

[/sourcecode]

tag from <a href="http://code.google.com/p/syntaxhighlighter/">SyntaxHighlighter</a>, then found another one, called SyntaxHilighter Plus.

I don't have time to go over all of this, but I disabled the Plus version, re-enabled the regular SyntaxHighlighter, and made sure to wrap my

[sourcecode]

s in <pre> tags.

Quick Answer: When you want a page break, switch to HTML/Code view and then type <!–nextpage–>.

Whole Story

As simple as this sounds, it took me 20 minutes to get this to work.  My problem was that I thought the usage was like other plugin quicktags, where you can just put it in anywhere.  But if you put in <!–nextpage–> while using the “Visual” or WYSIWYG editor, it will change your greater than and less than sign into the html entities.

The problem with having to switch to the HTML or code view is that I have to scroll down and find where my spot was in the article (if I am putting in page breaks after publishing).  It would be great if WordPress had a button on the writing toolbar, like the “More” tag, that would insert page breaks without having to switch to HTML or Code view, or worrying about whether you are in the right view or not.

This took me so much longer than it should have that this qualifies as a “computer problem that got in my way”.

Quick Solution: Use Disk Utility to Restore your old drive to your new drive, then tell Time Machine that you want to use a different disk

The Whole Story

When I got the 1TB drive, it was formatted as FAT32. I had been using Time Machine (I am running Mac OS 10.5.2) and I wanted to use my new drive for Time Machine, but I wanted to keep my current Time Machine history. My vision was to have the exact same data, but now my external drive can hold more. I ran into a few issues while trying to do this, so here is how I solved them.

Note: The sections “Formatting the new hard drive”, “Transfer the files”, and “Transfer Problems” narrate the problems I had while trying to just copy files… see the following section, “Use Disk Utility Instead”, for enumerated instructions on how I actually solved the problem.

Formatting the new hard drive

When I first plugged in the drive, Leopard recognized it. I thought that I might just be able to dump the files from my old external hard drive (formatted in HFS+) onto the new one (FAT32). When I selected the files to move and dragged them to the new folder, I heard the “pang” sound that Finder makes when you copy files, but nothing actually happened.

Since I will only use this new drive on a Mac, I thought maybe I should reformat to HFS+ (I also thought that Time Machine might require it). Using Disk Utility, I ran into a few vague errors and the disk would never be successfully formatted. I found the solution on the Apple Discussion Forums .

This basically says that you must select the highest parent of the drive you want to format

and select the “Partition” page.

Then go to “Options…” and select the top option: “GUID”.

The formatting should only take a few seconds.

The next page goes over transferring your files.

The quick answer: export your data and reinstall WordPress.

The whole story:

So I used the cPanel interface of the web hoster and created a subdomain, blog, and set the document root to /www/blog/. When I would try to pull up www.blog.thewebsite.com , the browser would just redirect to www.thewebsite.com/, and no blog would appear.

I was going to go through all of the things that I did to try to hack-up WordPress so that I would not have to reinstall, but then I realized that none of that actually worked. I could get far enough that the page would show up and about half of the links would work, but there ended up being an issue with the permalinks.

What I had to do was use the Manage->Export feature of the WordPress admin area to save my categories, posts, etc. Then, to uninstall WordPress, I deleted all of the tables in my WordPress database, then ran the install.php script again. I probably could have kept the users table, and perhaps a few other tables with the plugin settings, but I didn’t. So I had to reactivate my plugins and all of the other options that I had changed from the default values.

If you have a better fix for this, please leave a comment!