Two things broke in adding the WordPress permalink feature. This post describes those problems, attempted fixes and descriptions for each, then followed by current resolution and approach.

Why Permalinks?

Rather than use the ?page_id=num and ?p=num internal references for postings, WordPress provides a permalink feature that converts these ID references into URL strings that help in search engine indexing. Here is the permalink structure I settled upon for my site:

 /index/ai3v2/%year%/%postname%/

This produces a URL that contains a truncation of the post name title, plus other relevant information. That is well and good and the search engines would love me, but turning this feature on caused:  1) images were lost due to reference changes; and 2) Jonathan Foucher’s ‘Popular Posts’ plugin ceased displaying.

Lost Images

The first problem is that all of my site images no longer could be found. According to the last entries in the WordPress support file, I needed to add these lines of code to my main site index file:

  <?php $basehref = "http://".$_SERVER[‘SERVER_NAME’].($_SERVER[‘SCRIPT_NAME’]); ?>

    <base href="<?php echo"$basehref"; ?>">

As well, I needed to preface my internal image references by ‘/index.php/’. 

These changes again allowed my images to be properly displayed, but I guess I’m not sure why all of the pieces worked. With this first problem fixed, I could now address the second.

Popular Links

I use Jonathan Foucher’s ‘most popular’ plugin, which broke when I introduced a permalink without an ID field. This plugin itself relies on the Randy Peterson’s StatTraq statistical reporting plugin.

In researching this problem, I came across a posting by Jonathan noting the issue was indeed when no post id is included in the permalink structure. Because the post id is not added to the StatTraq table in the ‘article_id’ field, it causes the ‘page views’ StatTraq report to show only ‘Mixed’ page views, not the actual posts viewed by visitors. I tried his suggested resolution by making these line (25 and 26) changes in the stattraq.php file:

if (($p != '')){
$p = intval($p);

With this replacement:

 if (($post->ID != '')){
 $p = intval($post->ID);

Unfortunately, that did not fix my problem.

Resolution

Since I could not get images and popular links to work simultaneously, I decided to pass. I suspect that late updates to StatTraq and WordPress will better address these problems (Randy has announced a pending update for StatTraq). While I like the fact these tools are extensible and many discuss successful hacks, it does concern me to hack code unnecessarily that might make installing later upgrades and bug fixes even more problematic.

So, in thnking about the fact that AI3 is likely to be very content-filled anyway, I decided to put off resolving the permalink issue until another day. I’d already spent too many hours on a dead-end.

Author’s Note:  I actually decided to commit to a blog on April 27, 2005, and began recording soon thereafter my steps in doing so.  Because of work demands and other delays, the actual site was not released until July 18, 2005.  To give my ‘Prepare to Blog …’ postings a more contemporaneous feel, I arbitrarily changed posting dates on this series one month forward, which means some aspects of the actual blog were better developed than some of these earlier posts indicate.  However, the sequence and the content remain unchanged.  A re-factored complete guide will be posted at the conclusion of the ‘Prepare to Blog …’ series, targeted for release about August 18, 2005.  mkb

After some days of delays doing my normal day job, I was able to return to getting the site ready.

The key things for today were setting up the relationships, linkages and accounts with entities like Blogstreet, etc. I was very impressed with how easy it was to add these systems; their Web sites and on-site instructions with accompanying HTML and Javascript (if used) were excellent.

I set up links for:

• XML (RSS feed)
• BrightPlanet
• WordPress
• Technorati
• Blogstreet
• Site Meter
• Creative Commons
• W3C XHTML Validation (added later).

I will continue on getting this prep stuff done, but upcoming business travel may push out my desired site release a few days further.

Author’s Note:  I actually decided to commit to a blog on April 27, 2005, and began recording soon thereafter my steps in doing so.  Because of work demands and other delays, the actual site was not released until July 18, 2005.  To give my ‘Prepare to Blog …’ postings a more contemporaneous feel, I arbitrarily changed posting dates on this series one month forward, which means some aspects of the actual blog were better developed than some of these earlier posts indicate.  However, the sequence and the content remain unchanged.  A re-factored complete guide will be posted at the conclusion of the ‘Prepare to Blog …’ series, targeted for release about August 18, 2005.  mkb

After deciding that Xinha would be the WYSIWYG editor of choice (at least for the time being), I asked Kevin Klawonn, BrightPlanet’s most capable sys admin, to tackle the integration task. Here is his report on his experience; I’m sure later posts will update this matter:

Incorporating Xinha into WordPress has been more than a frustrating experience. I was hoping that because of the appearant widespread use of WordPress and Xinha, the integration would be seamless. At a bare minimum, I was hoping that someone else had achieved and documented exactly what I was trying to accomplish. After looking into how WordPress handles plugins, my goal was to configure Xinha so that it would be similar to the existing plugins. I wanted to be able to drop the Xinha folder into the plugins folder, click the activate button in the admin console, and have Xinha "magically" appear in the editing boxes of WordPress. However, this was not the case.

What I found was that for Xinha to work (sort of), I needed to do just as the instructions said and do some hardwiring into the existing pages of the blog. Once I had the new editor working on one page, I went back to looking into making the integration simpler. After scouring several sites for information and spending quite some time on the task of making the implementation of Xinha simple, I am back to the idea that I just need to make Xinha work. Now that I am back on the track of just getting it to work, I am still confronted with some problems.

In the Newbie Guide for Xinha, it says that the textareas that are to be converted to Xinha editors need to have their names listed in the my_config.js file. The two text areas, the ones on the edit-page-form.php and the edit-form-advanced.php pages, both have the id of "contents". So in the my_config.js file I entered "contents" in the appropriate list. I checked the two pages, and only the editor on the edit-form-advanced.php is using Xinha. Why would one work and not the other?

I read every entry I could on the Xinha website. The only thing that came remotely close to helping was a debunked entry saying to change the:

"window.onload = xinha_init;" line at the bottom of the my_config.js file to read "window.onload = xinha_init();"

Immediately following that entry on the website was another saying to NOT do that because it completely changes the meaning of that line and can have unforeseen consequences. I tried it anyway. Both editors appeared correctly. Unfortunately, if a person refreshed the webpage, the Xinha editors were replaced with the regular text areas. So adding the "()" to that line did not work correctly anyway.

Another problem that I have encountered so far with the Xinha editor is that when I do get it to work on a page, it only appears correctly when I use Firefox v1.0.4. If I use Opera v8.0 Xinha does not appear at all. If I use IE v6 I only get a partial view of Xinha. In my research I have found no one else that has these problems. So, once I finally get Xinha working on all the appropriate pages, I then need to find out why it is not working for certain browsers.

Our objective in this continuing effort is to get Xinha integrated as a true plug-in, allow it to be switched on of off with with existing minimal editor, ensure it works across browsers, and other things we have not yet discovered.

Nonetheless, Kevin has done a great job in areas I can’t even fathom. It is clear that some blog tasks should not be tackled by mere mortals.

Author’s Note:  I actually decided to commit to a blog on April 27, 2005, and began recording soon thereafter my steps in doing so.  Because of work demands and other delays, the actual site was not released until July 18, 2005.  To give my ‘Prepare to Blog …’ postings a more contemporaneous feel, I arbitrarily changed posting dates on this series one month forward, which means some aspects of the actual blog were better developed than some of these earlier posts indicate.  However, the sequence and the content remain unchanged.  A re-factored complete guide will be posted at the conclusion of the ‘Prepare to Blog …’ series, targeted for release about August 18, 2005.  mkb

Though I’m impressed with how quickly a blog can initially be set up and released, I guess I have more of a game plan like Patton invading Sicily prior to releasing my site. There’s a whole culture, language and set of technologies with which I’m not yet familar. Since once a site goes "live" it’s hard to hide stupidity, I guess I’m trying to understand things better to lessen the inevitable IQ decrement. I’m also sure that in a few weeks time I will look over this list with wonderment as to how much of a newbie I really was!

Some of the major items and specific tasks, none in particular order, that must be done and learned to getting this blog running on a routine, easily maintaned basis are:

• Posting and comments formatting, utilities
• Completion of Blog Web page content
• Figuring out navigation and external link references (the general blososphere connectivity)
• Longer-term functionality and its integration
• Efficient (?) update and maintenance procedures.

As items get completed and may reference other posts, I’ll return and add the internal links.

General Editing

1. Generalize the CSS style sheet, with more objectification and logical class names
2. Create more consistent, minor style sheet classes and see if they can be referenced through a WYSIWYG editor (below)
3. Learn how to have more WYSIWYG editing
4. Learn how to enter standard HTML formatting into new post entries (incl. using bullets and numbered lists; when this displays OK that has been accomplished)
5. Distinguish between list types
6. Add a standard WYSIWYG editor
7. Figure out procedures for moving existing and developing Word content for posting to the site.

Posts and Comments

1. Decide about use of email address on site and for author posting comments –> do others have concerns about email capture for spam and does that suggest some captcha capability?
2. Figure out how to split long posts — such as some of the main articles and white papers I intend to post — into multi-part segments
3. Figure out if there is a slick way to use classes or styles for HTML insertions
4. Add mechanisms for emailing a post, printing a post or downloading a PDF (where that makes sense)
5. Add a standard Next – Back set of links at the bottom of every post for easier internal navigation between posts
6. Work out the kinks in the entire Comments to posts area, specifically whether minor WYSIWYG editing should be provided and how to preview comments before posting.

Site Pages

Major templating of a few page types has already been done. However, text and templates for "standard" internal pages are needed for:

1. 404 error
2. Copyright
3. About me
4. About me (detailed and bibiography)
5. About site (mission)
6. BrightPlanet page
7. DiDia page
8. Masthead picture reference
9. Chronology listing (work out formatting, plugin and PHP)

Navigation and External Links

1. Add external links, GIFs where necessary, and do the registrations as appropriate for:
• RSS (XML)
• BrightPlanet
• Blogstreet
• Site Meter
• Technorati
• WordPress
• The selected Wiki
• Creative Commons stuff
2. Limit some pages from appearing on site navigation
3. Reserve, but don’t yet implement, the entire advanced feature anticipated for detailed categorization and placement
4. Replace the current footer section; the queries stuff seems silly
5. Separate out the calendar and archive sections

Wiki Integration

Find a Wiki tool that:

• "Plays nice" with the WordPress environment
• Can use the same style sheet
• Can use the same editor
• Has posted content that is seamless with the site for such things as site searching, categorization, etc.

Other General

1. Research and better understand some of the spam and privacy protection concerns, especially in comments, emails, robots interactions and others
2. Figure out the email return thing where the title line requires the sender to do clever replacements
3. igure out the Permalink think
4. Figure out the Trackback thing
5. Figure out the Blogroll thing and decide if I want to use that feature or not
6. Get a better search function and box
7. Figure out procedures, icons, etc., for allowing PDF download capabilities
8. Figure out how to archive and get formatted posts and pages from the MySQL database.
9. Add shortcut icon (favicon.ico) for appearing in the browser address bar.

Final Release

1. Clean up all entries
2. Add date stamps/updated dates to all main pages
3. Fix all broker links
4. Finalize all styles, sizings, positions
5. Complete and update this start-up checklist
6. Write up an document best practices for starting and then running a blog.

Stuff to Defer Until After Initial Release

[Note:  these items were added just prior to initial release.]

• Defer improved search function
• Defer Wiki integration
• Defer adding advanced categorization.

Author’s Note:  I actually decided to commit to a blog on April 27, 2005, and began recording soon thereafter my steps in doing so.  Because of work demands and other delays, the actual site was not released until July 18, 2005.  To give my ‘Prepare to Blog …’ postings a more contemporaneous feel, I arbitrarily changed posting dates on this series one month forward, which means some aspects of the actual blog were better developed than some of these earlier posts indicate.  However, the sequence and the content remain unchanged.  A re-factored complete guide will be posted at the conclusion of the ‘Prepare to Blog …’ series, targeted for release about August 18, 2005.  mkb