I hate that.

But then comes this - hacking WP URLs to get a feed. Perhaps TypePad does something similar? And sure enough, it does. The trick was getting the blog folder from looking at the permalinks, and referencing the feed's atom.xml file.

Update: unclear, at least in Google Reader. I'm going to have to get clever with wget to take a look at the raw XML.

Update 2: It helps to actually tell Wordpress to publish the full text of the article. If you're following along at home, go to Options | Reading and make sure the Syndication option isn't set to Summary.

Update 3: Wordpress has now been upgraded to v2.3.1; several plug-ins got updated as well. It doesn't seem to help the feeds in GReader though - they're still butt-ugly, with no apparent <p></p> or <br /> tags, or any of the textile formatting.

Well, he told all his friends, and lo and behold, crunchy Firefox delights are spreading!

¹ Does that make Dan my brother-in-law? Maybe a brother-in-law once removed? Or maybe he's a second brother-in-law, and my sister's husband is a brother-in-law once removed. Or maybe I'm just waaaay to caught up in this.

There's a feature request for article expiration in the works, which helps me not at all. However, some looking around brought me to the wonderful chh_article_custom plugin, which does exactly what I need it to. However, it took me much too long to figure out how to get the beast installed.

The plugin looks like¹

< ?php $plugin='YTo4OntzOjQ6Im5hbWUiO3M' ? >
</>

where the string of gibberish is a uuencoded (or some encoding) of PHP code. On the plugin admin page, you get two boxes: "Install Plugin", with a textbox, and "Old-style (text file) plugin installer", with a file chooser. Both boxes have a help button associated with them, that returns... absolutely nothing. I remembered (from having installed one plugin successfully) that I needed to paste the plugin into the textbox. However, doing that gives a "Badly formed or empty plugin code" error. Well then, perhaps using the old-style installer... nope, same error.

It took me about 30 minutes of searching the forums and googling before I figured out that what gets pasted in the textbox is what's between the two single quotes. So, for the example above, I'd paste just YTo4OntzOjQ6Im5hbWUiO3M.

Arggg! Why isn't this more clear? And why isn't it at least in the help?

But now, at least, Google has some prayer of retrieving something about this, in case some other poor soul needs it. And mondo mad props to Coke Harrington for making my life easier.

¹ Why does WP muck up the PHP string? Does it have something to do with the backslash issue, where my hindbrain is telling me that there's a known issue about WP swallowing backslashes, and you have to escape them?

Now for the nitty gritty. The 5-minute install pretty much nails it, and makes MT's install process seem painfully technical. The only problem I had was getting the blog URI to show up correctly (I never did, and resorted to installing WP in the docroot of the webserver). Importing MT entries was a breeze that I made too complicated. It turns out I didn't have to worry about creating users ahead of time, as I found out the second time I did the import (over the first time; no worries about duplicates). I had to import the second time because I needed to turn on Textile formatting for the import; it Just Worked. I will say the wiki-style table here didn't come over too well, but it wasn't great in the first place. I'll have to go back and update it from Textile 1 to Textile 2, and perhaps it'll be better.

I still need to update the styles, but that's it. Then comes the fun of poking around and seeing how things work, getting comfortable. It's like getting a new car, and getting used to the dashboard layout, the seat controls, and the climate control. And the stereo. And the V6

The upshot is the deluge of comments from all my adoring fans may not get propagated, should any be made this weekend.

Here's a short example: The user has to select which CRMA solution types their company provides in their products and solutions. The choices are:
* Sales
* Marketing
* Service/Help Desk

I started out writing this as:
$form->addElement('advcheckbox', 'solutionType[]', 'Type of solution (check all that apply):', 'Sales', null); $form->addElement('advcheckbox', 'solutionType[]', null, 'Marketing', null); $form->addElement('advcheckbox', 'solutionType[]', null, 'Service/Help Desk', 'null');

Checking the first option gives me the following $_POST variables:
[__solutionType] => Array ( [0] => 1 ) [solutionType] => Array ( [0] => [1] => [2] => )

I could work with this, but what I'd like to know isn't that the first element of the array is checked, but that 'Sales' is checked. Then I experimented with adding the checked value attribute to addElement as the last parameter:
$form->addElement('advcheckbox', 'solutionType[]', 'Type of solution (check all that apply):', 'Sales', null, 'Sales);

The other lines were treated similarly, but the output didn't change at all. After tracking down the only relevant entry Google could find on "quickform checkbox variable", I was able to deduce that I needed to define each element of solutionType[] specifically (again, only showing the first element as an example):
$form->addElement('advcheckbox', 'solutionType['Sales]', 'Type of solution (check all that apply):', 'Sales', null, Sales);

Now the output is:
[__solutionType] => Array ( [Sales] => 1 ) [solutionType] => Array ( [Sales] => Sales [Marketing] => [Service/Help Desk] => )

Defining it like this, I can use the __solutionType array's keys to tell me the exact text of the elements that the user selected. Note that if this code is used in conjunction with defaults (for instance, if and when I allow the submitter to edit the values, I'd want to load it up with what they originally submitted), I'd probably want to use the solutionType array instead, or pay attention to the values of the __solutionType array to handle the case when the user unchecks an option.