Category: Weblogging

A Missouri woman heads to American Streets

Post author By Shelley Powers
Post date July 20, 2004

Starting this next Sunday, I’ll be writing a weekly essay at The American Street–my first time as contributor to a group weblog. Each essay is a longer writing, and may or may not include links. Though the topic will vary from week to week, I hope to bring a unique perspective to each that reflects, among other things, being a woman living in Missouri. Since it’s been said by those who say such things that women prefer facts over theory, you might say I’m providing the show me sex in the show me state viewpoint.

(Speaking of which, Missouri, an important swing state in the upcoming election, is also the site of one of four presidential debates scheduled for this Fall. It’s also a popular campaign stop for both parties, as witness President Bush’s visit today.)

I’ve resisted group weblogs in the past, preferring to keep all my writing here in my own space. What changed my mind in this case–aside from the other excellent writers at The American Street, not to mention my respect for Kevin Hayden–is that I want the discipline that comes with writing in another’s space, and at specific times in the week.

I’m writing on impulse too much lately. Writing impulsivly is not the same as being fresh and spontaneous. There is an element of ‘knee jerk’ reaction to impulsive writing, and I end up regretting such writing, more often than not.

Unfortunately, there’s a lot of material lately that leads to reactive behavior, much of it political in nature. I’ve been reading the top linked stories the last few week and I’m seeing a new element entering into weblogging; we’ll call it the “Fox” element for want of another classification. You can see it with the relatively new weblog written by Michelle Malkin, who happens to be, among other things, a Fox News Contributor.

Malkin has looked at weblogging and seen what it’s done for Wonkette and others, and has enthusiastically jumped in. She’s a real pro, too, having written for the New York Post and National Review Online, as well as being trained by that media maw that is known as Fox. Though we can laugh and sneer at Fox’s lack of credibility, make no mistake–it is the highest rated news station in the country now. Fox sells here in Missouri. Fox sells in a lot of places.

Malkin has, quickly and efficiently, demonstrated how to push the right buttons with her writing. Though I am pleased to see a woman gain such immediate attention, I am less than sanguine when I read her form of journalism.

Malkin succeeds by generating impulsive reactions. Whether they are reactions for or against (primarily for, at this time), there is something about her writing that makes me, at least, want to sit down in a heat of anger and write a blistering refutation.

However, the problem with this kind of reaction is all we’re doing is responding to having our buttons pushed; instead of providing a counter-point, we’re providing a chorus. It’s somewhat comparable to Fox News and that new documentary, Outfoxed. Is Outfoxed outfoxing Fox? Or will it be outfoxed itself as Fox’s audience increases rather than decreases over the next several months, thanks in part to this documentary. The documentary and that foolish MoveOn challenge of Fox’s slogan, “Fair and Balanced”, I should add.

Rather than immediately respond to Maltin’s writings, or other events just as heated and reactive, with many postings barely controlled, I’m hoping that by picking one specific topic, thinking about it carefully and calmly and then writing about it on a specific day, to a weblog shared with other people, my writing will not only be more disciplined, but more effective. The writing can still be as passionate; hopefully, though, it will also be thoughtful, cohesive, and coherent.

(Not to mention spell checked, and carefully edited for grammar. Not, toomany, comma’s or other punctuation an grammar errors other other typos in the writing of it.)

My appreciations to The American Street folks for inviting me in.

Now, I may be more thoughtful with my political writing at The American Street, but I’ll still blather incoherently about everything else here, or in Practical RDF. Just in case you were worried.

Unfortunately, reading popular political weblogs from all sides of the fence, I have a feeling my approach is not going to gain The American Street any fans.

Technology Weblogging

Talkback as plugin

Post author By Shelley Powers
Post date July 13, 2004

In my last post on WordPress, Carthik asked about my “Talkback” implementation. I hadn’t included this as part of my WordPress modifications because I’ve had the beastie since Movable Type times and didn’t think of it as a WordPress mod. However, I’ve since converted it into a WordPress plugin; you can access the text of the plugin here. Just copy this into wp-content/plugins/, rename it talkback.php, activate it and you’re good to go.

This particular plugin incorporates my fulltext implementation, so the code does need to be modified if you’re not using this. Look for the comment in the code that begins with “// if you don’t implement multi-page fulltext…” and follow the instructions accordingly.

To invoke the plugin, in a separate page, which I’ve called speakback.php, include the wp-blog-header.php in the beginning of the page, and then just call the function:

talkback();

Formatting is already included in the output.

The simplest approach would be to copy index.php, remove the guts of the main body, and replace it with this function call.

Then in your comments, call the page like so:

Talkback: <a href=”/speakback.php?name=<?php comment_author() ?>”>By name</a> <a href=”/speakback.php?url=<?php comment_author_url() ?>”>By URL</a>

Clicking on the name or URL will then bring up a page of the person’s comments at your site.

Diversity Political Weblogging

Women blogging the Convention?

Post author By Shelley Powers
Post date July 7, 2004

Recovered from the Wayback Machine.

Since I’m on a roll about women’s apparent invisibility in weblogging circles, well except when we’re naked or shoving our titties in front of the faces of the boys, I am curious: which women bloggers have been credentialed by the Democratic party to cover the Convention?

We’ve already heard that a person infamous for indiscriminate and malicious comments about women has been given access. I’d like to think there might be a woman or two among the fifty or so men who will be going, so that the Convention goers don’t think weblogging is a boys only club.

Not that we think it is.

Of course not.

We all be equal here, we be.

update

At least it’s nice to know that we women don’t suffer blogger burnout like the guys.

Burningbird Technology Weblogging

WordPress modifications

Post author By Shelley Powers
Post date July 7, 2004

Recovered from the Wayback Machine.

Rather than cover each modification I’ve made to WordPress 1.2 to run my site just so, I’m including them all here with links to downloadable source for those interested in implementing one or more of the changes.

Very few of these changes fit into the criteria of ‘Wordpress plugin’, primarily because most require at least a small code change to the existing application. The code changes within the application can be minor–such as adding a link in the menu for a new application page within the WP administration. Other changes, though, while not necessarily extensive, can be more challenging because of knowing where to make the code change; adding in the ‘moderated’ and ‘insert’ options into administrative edit page fits this second type of change. Regardless of the extensive nature of the change, upgrading to the next version of WordPress will overwrite these changes. My plan is to port whatever of these modifications haven’t been implemented in WP over to the next couple of releases, and then we’ll see what happens from there.

Hopefully, though, the WordPress team will consider incorporating some of these changes, such as the per-post moderation and full-page preview, the static generation of the syndication feeds, full text for broken up documents, and something like the self-policing comments. These are the toughest to incorporate by non-developers, primarily because it’s difficult to see where to add the code. However, these changes have made a real difference to me and from what I’ve read of others’ interest, they could make the difference for other folks, too.

Cleanup

First thing to do after installing WordPress is get rid of files you’re not going to use. Create a separate directory somewhere and move the unwanted files there, in case you discover you do want them at some future time.

For my installation, I’m only supporting Atom and RDF/RSS (RSS 1.0) syndication feeds, so I got rid of wp-rss2.php, wp-rss.php, and wp-commentsrss2.php. I also don’t support site registration or use OPML, and eliminated wp-register.php and wp-links-opml.php. In addition, I dropped the readme.html file, and wp-layout.css since I don’t need the former and I have my own stylesheets.

Within wp-admin, once everything was installed and imported, I dumped the import*.php and install*.php pages. The only ones showing in my source code downloads are those for my own modifications.

Since I’m not using sidebar links, I could also get rid of the link related pages, such as link-add.php and others, but I may come up with a purpose for this technology at some point, so I’ll leave them for now.

The reason you want to keep your site as clean as possible is that every PHP page is a doorway into your site. The door may be locked tight, and seem impossible to force – but why keep a functional page around when you’re not using it? Especially with the import and install applications: running them again may not hurt anything, but why keep them around for someone to run again?

Having said that, though, don’t delete the pages; just move them of the server, or to an area where they can’t be accessed via the web.

Creating separate category and individual files

At this time, all requests for category, individual, or archived posts go to the same file that serves the main page: index.php. However, I prefer a different look and feel with my category and individual displays, so the first modification I made with the WP installation was add these separate files.

I copied index.php to new files called individual.php and category.php. Aside from the modifications to the appearance of each page, I made the following code changes to individual.php:

1. I added in the “next-main-previous” navigation links at the top of the page, above the date. Checking out the source, this is lines 52-56, including the enclosing DIV tags. The actual code is on line 54. Note that this code has to be within The Loop as the WordPress development team refers to the post processing loop, beginning at line 38.

2. I kept some things in the individual page that I removed from the main index.php page. For instance, I kept the trackback autodiscovery function call at line 75, and the call to the embedded code to handle comments, wp-comments.php, at line 82. These aren’t useful in the main page, so why keep them around cluttering up the code?

3. Instead of a note about a post not being found, I redirect all missing posts to my main Missing Page. The reason for this is that it looks a lot better than the message; and it returns a permanent redirection status code to the calling page. A better option might be to return a 410 status code so that webbots know the resource is gone. Perhaps a future change.

I made the following changes to the category.php page:

1. I removed the RDF trackback function call and the wp-comments.php reference in category.php, as these aren’t useful in a category context. I also removed any other function call that wasn’t needed. I’ll probably do even more cleanup in this and the other pages.

2. I replaced the full post content function call from the main page (the function called ‘the_content’) with an excerpt at line 55. I prefer just showing excerpts on my category listing page.

Once the individual.php and category.php pages have been created, then it’s just a matter of redirecting requests to them rather than to the index.php. This occurs in the .htaccess page.

I used the following custom template tag structure for my Practical RDF entries:

/archives/%year%/%monthnum%/%postname%

With this, my individual items can be accessed using what we’ve come to know as ‘cruft-free’ URLS, consisting of the date and either post title or post slug (abbreviated title).

When I added this custom URL, WordPress generated text I added to my .htaccess file. It’s this text that I needed to modify to use my new pages. I’ve included my copy of .htaccess in the download, but the lines that are pertinent now are the following:

I changed this:

RewriteRule ^archives/([0-9]{4})?/?([0-9]{1,2})?/?([_0-9a-z-]+)?([0-9]+)?/?$ /index.php?year=$1&monthnum=$2&name=$3&page=$4 [QSA]

To this:

RewriteRule ^archives/([0-9]{4})?/?([0-9]{1,2})?/?([_0-9a-z-]+)?([0-9]+)?/?$ /individual.php?year=$1&monthnum=$2&name=$3&page=$4 [QSA]

And I changed this:

RewriteRule ^archives/category/?(.*) /index.php?category_name=$1 [QSA]

To this:

RewriteRule ^archives/category/?(.*) /category.php?category_name=$1 [QSA]

Now, instead of index.php getting requests for all the pages, individual post requests are directed to individual.php, and category pages are directed to category.php.

I also removed some of the other WordPress generated .htaccess entries, such as those for syndication feeds of my categories and comments. I would prefer being given the choice whether these are syndicated or not, so have removed them for now.

Fullpage Preview

What I found frustrating with most of the weblogging tools I’ve used in the past is there is no way to preview a post in context. In other words, no way to preview a post, as it would show once published, within the same page constraints and look and feel as govern the post once it’s live.

One of the first tweaks I made to WordPress was to provide full page preview. Even when WordPress 1.2 came out with a preview item at the bottom of the edit page, I opted for my approach, which was a separate preview page and a link in the edit form to open it.

(I’ve since removed the code for the in-page preview from the edit form as it plays havoc with the larger essays.)

To create the preview page, I first copied my individual page, individual.php, to a new file, calling it preview.php. Since the header file in both only shows posts that are published, I also needed to make a copy of wp-blog-header.php, calling this new page wp-blog-draft-header.php. The new header page is exactly like the old one except that in the source, I changed the code at line 312 to access posts with status of ‘draft’ rather than ‘publish’. I then replaced the call to wp-blog-header.php with wp-blog-draft-header.php in preview. php, as shown in the source at line 14.

To call this preview page from the application, I added a hypertext link to the page in my edit-form-advanced.php page, at line 162, passing in the post identifier.

Now, when editing a post, clicking on the “Preview” link opens that post for preview exactly as it would look in the individual posting page.

On demand by post comment moderation

The second major modification was to add post-by-post moderation. At this time, WordPress only supports moderation for the entire site, but I want moderation of specific posts. This additional functionality required changes in the code in a couple of different places, and also required a minor database change.

First, there is no comment_status enumerated value of ‘moderated’ in the WordPress database posts table. (An enumerated value is one where options can be accessed as numbers, or as named values, which are easier to remember. )

I used PHPMYAdmin to add ‘moderated’ to the end of the list of other enumerated values. To do this directly in the MySQL command line, use the following:

ALTER TABLE `rdf_posts` CHANGE `comment_status` `comment_status` ENUM( ‘open’, ‘closed’, ‘registered_only’, ‘moderated’ ) DEFAULT ‘open’ NOT NULL

Next, I added the ‘moderated’ option to the list of other options within the WordPress edit page, as can be seen in the source in line 98. Now when the Edit page opens, ‘moderated’ is one of the comment options.

In the front end pages, in wp-comments.php, I added a note about moderation, and the reasons that it’s turned on, in lines 78 and 84 through 87. In wp-comments-post.php, I added code starting at line 110 to turn on moderated comment handling.

One last change I made fairly recently was to automatically set a post comment_status to moderated if it’s currently open, but over 20 days old. I added this within wp-comments-post.php, from lines 76 through 85.

That’s it for comment moderation. Now, I can set a specific post to be moderated as soon as I publish it. Or I can turn comment moderation on for several posts based on date or some other factor, by running a SQL update directly against the database and setting the posts’ comment_status to ‘moderated’. Finally, a post sets itself to be moderated when a person adds a comment to the post and it’s over 20 days old.

I may pull some of this code into a separate function just to clean up the page, but the functionality will remain the same.

Comment formatting and comment/trackback split

A change I made back in WordPress 1.02, was to split the display of comments in the individual page between trackback/pingbacks and comments. I also added formatting for the comments, by wrapping the comment area in a DIV element with a specific CSS class, and by providing my own author formatting.

I created two plugins to support these modifications. The first, get-comment-type.php has one function that returns the type of comment after examining the comment contents. The second, get-comment-author.php does all sorts of formatting on the author, using the same technology I used when I formatted the author while running an MT weblog.

In wp-comments.php, the comments are looped, and each is checked for type. If the type is trackback or pingback, the item is printed out, as shown in lines 45-57. Note in the code in line 48 the call to get_comment_type to get the comment type. Also note in line 54 the call to get_comment_author.

The same look and processing is also used with comments, in lines 59-71.

Formatting is added around the comment_text function call in lines 52 and 66. The CSS styling can then be controlled with each stylesheet.

Spam Control

Control for spam is mainly handled by setting older posts to be moderated, but to stop a ‘crapflood’ or a whole of lot of spam comments being added at once, I use a modification of the code that Jacques Distler originated, I believe: only allow so many comment postings within the same time period.

The code to help prevent flooding can be found in lines 87-101. First it checks to ensure that the same person hasn’t posted a comment within the last ten seconds–code provided from the WordPress development team. My addition is the code following, which checks to make sure there have been no more than 50 comments in the last day–any comments beyond that are automatically moderated. I’m no political pundit to get a lot of comments during the day, and 50 seemed sufficient.

Static page generation

Comment flooding just isn’t as much of a problem for WordPress as it is for Movable Type because a comment in WP is not much more than an insertion of a new row in the database. With MT, re-building of pages is happening, and that’s intensive.

If you think about it, mid-range web sites that provide database activity usually get several thousand database accesses or updates in an hour, much less a day. Few webloggers will meet or exceed this. But page rebuilding using a template language library is a very CPU hungry process. It’s because of this that I don’t generate static versions of all the pages when I re-build (more on static pages later). It’s more efficient to dynamically serve the pages, then rebuild when they’re new, or have been newly commented.

However, syndication feeds are different. The only time these should be changed is when entries in these pages are added or modified. However, the little buggers get accessed frequently – much more frequently than our main pages now. It makes sense to provide static versions of these pages.

The code I use to create static pages from dynamic content is fairly well known code. First, you grab a copy of the page in memory. Then you write it out to a filem usually located in the /tmp directory in Linux. Finally, when the file has been completely written out, you copy the page from /tmp to its permanent location.

You can see this code here . This function, which has been created as a WordPress 1.2 plugin, takes two paramters: The URL for the source, and the target file name. When installed, the person using the plugin needs to modify both the static HTML directory and the name of the temp file. The function call at the end – unlink – deletes the file.

The Unix /tmp directory is nothing more than a temporary directory where most users on a machine can write intermediate results, just as I am with this code. By writing the file to the TMP directory until finished, I don’t overwrite any existing version of the file, in case a problem happens and my write isn’t complete. If the program crashes in mid-write, there are mechanisms that keep /tmp clean so breaking program cleanup is not an issue. No bits of have burnt files to worry about.

Now that a static generation function exists, I can use it in two different ways: to generate static content based on an action, or on demand.

A second plugin, gen-static-main.php generates a static version of my RDF/RSS 1.0 file and my Atom syndication file. Through the use of the WordPress plugin architecture, this function is called any time the publish_post or edit_post action is initiated. Since I am following the requirements of the architecture, my function will be past the post identifier, which I have to return.

Now, any time I edit or publish a post, my static syndication feeds are created. I then use soft links to link these to my main directory:

ln -s /home/shelley/www/weblog/static_html/index.rdf index.rdf

For creating static versions of any page, I created a new WordPress administration form, get-static.php that takes a source URL and a target file name and generates the static version of whatever I give it. It can be my weblog entries, or others – it works equally well with any web page.

To add the new form to the administrative panel, I added an entry into the menu.php file at line 26.

Simple, and a sweet addition to the application.

(Note in menu.php that I’ve also removed the link to templates and links, since I don’t currently use either of these pages at this time.)

Fulltext

I like the use of WordPress’ nextpage functionality. With this, people can link specifically to individual items rather than the document as a whole. And it helps cut down on the page length for larger articles, such as this one.

However, two valid concerns about the implementation are: there is no way of overriding the page breakups for those who want to print the page, or not scroll; and comments repeat on every page and this can be confusing. Enter my Fulltext implementation.

The function responsible for splitting content into pages in WordPress 1.2 is start_wp. I created a plugin that has my own implementation of this function, fulltext-plugin.php that does everything the original does, but replaces nextpage with spaces instead of conceptual page breaks, as seen in lines 46-48.

Next, I copied individual.php to a new file called fulltext.php. This page is exactly the same as individual.php, except that it calls start_my_wp instead of the original function, in line 39.

To add a link to this page from my weblog pages, I modified index.php to check to see if the post is a multi-page and if so, provided a link to fulltext.php. This code can be seen on line 54. I also added code into the individual.php page to add this link, but also to prevent comments from showing in any page but the last page of the post, as seen in lines 78-83.

Now, any post that is split into multiple pages, like this one, also provides the facility to view it in its entirety.

Inserted pages

I’ve found over the years that at times I want to create pages in the weblogging tool, but not have them as part of the overall page navigation; I don’t want them to show on the front page, or be part of the archival lists. To support this concept in WordPress, I created a new post status called ‘insert’.

First, just like with the previously mentioned comment_status change, I added a new enumerated type of ‘insert’ to the post_status column in the database, using the same technique described with the ‘moderated’ change.

Next, I added this new type to edit-form-advanced.php, at the end of line 92. When this option is picked, the post won’t be displayed in the category, individual, fulltext, or main weblog pages.

To display this page, I copied the preview.php and wp-blog-header.php pages. The new header page, wp-blog-all-header.php has one change, to allow any posts other than those designated as ‘private’, at line 313. This new header is called in the new individual page, insert.php. Other changes to insert.php are to remove comments, as I don’t want comments in my inserted pages.

These new pages can be used as inserts for weblog posts, or to create about pages or other information pages that need to be publicly accessible, but not archived, syndicated, or posted on the front page.

Documented elsewhere

I discussed the Pithy Bar/Linklog implementation here. My multi-weblog support was discussed here. Note that with the release of 1.2, only the wp-content and wp-images subdirectories can be shared.

The technology for live comment preview at my sites was provided by Chris Davis and it has worked out to be a marvelous addition.

Other changes and the implementation of Steve Levy’s wonderful file upload enhancement are detailed here. My initial discussion on installing WordPress is here. Implementing the category image hack and other information is detailed in this post.

You can download a copy of the files I need to run my site, in G’zipped format or in a Zipped file, and I will update the documentation pages whenever I make a change.

Burningbird Technology Weblogging

Pithy bar

Post author By Shelley Powers
Post date July 4, 2004

Sidebar quick links, or b-links are very popular now. I wasn’t that interested at first in them until I found myself wanting to point out items of interest, but without writing a great deal about the item. I don’t necessarily like doing little posts with nothing more than a link, so b-links really is a good alternative.

What especially sold me on the concept was Mark Pilgrim’s b-link implementation. I found his style to be non-obstrucive, but more, I really began to enjoy the little comments he would add as TITLE attribute with each link. We talk about the skill and effort it takes to write lengthy essays, but it takes an equal or greater skill to sum up your view or opinion in one pithy little statement.

A b-link compliment is a nice,elegant way of saying, “Look at what you’ve done”, rather than not saying anything at all. They’re also a great way of pointing out something that doesn’t need any additional words, for one reason or another; or of saying to another: I hear you. Additionally, I found that one can use a variety of tones, from snippy to snarky, in a this type of b-link and they don’t seem to come out as heavy as they would in a regular weblog posting. Rather than be deliberately and ponderously offensive, these types of little communications become more a caustic little jab, or even a joke between friends.

Perhaps this effect is just Mark’s way with pithy statements; or perhaps it’s the brevity of the statement and the nature of its delivery – it becomes more an aside whispered under one’s breath than shouted from the pulpit.

So, I decided I wanted b-links. Specifically, I decided with my weblog re-design that I want a Pithy Bar.

Now something like a pithy bar isn’t necessarily easy to do in any weblogging tool, WordPress or otherwise. They’re usually created as separate categories for sidebar linking; or a separate weblog and getting the entries from the database, or scraping the syndication feed for the links. These work well, but it was more than I wanted in my implementation.

I wanted to add a link and have it show–bang! That’s it. Clean and simple. So, time to break out the code.

I created a table called “linklog” and added it to my WordPress database. The table has the following fields:

id – autoincremented identifier
title – What shows with the link on the page
url – b-link URL
blurb – the aside that’s added to the TITLE attribute of the hypertext link
viaurl – If found through another site, a link to that site

All fields are type ‘text’ except for the id.

I next created a page called linklog.php, which I added to my wp-admin directory. This page has a simple form that checks to see that the values are provided when the form is submitted, and inserts a new row for each linklog entry into the database. It also displays the last five linklog items, just to make sure you don’t add the same one twice.

To have this page show up in my installation of WordPress, I added an item to menu.php to point to this page (highlighted):

$menu = array(
        array(__('Write'), 1, 'post.php'),
        array(__('Edit'), 1, 'edit.php'),
        array(__('Profile'), 0, 'profile.php'),
        ....
 array(__(’Linklog’),0,’linklog.php’)
);

Finally, I created a WordPress plugin that has a function, my_linklog, that takes the number of links to display, and a special separator string that can be used between the items. The following is how I call the function in my main page:

<?php
my_linklog(10, ‘–. — — –. .-.. . / -.. ..- … -’);
?>

By default, the number of items showing is 5, and the separator string is empty (‘’).

Each item that is displayed is wrapped in a DIV element, with a class name of ’sidecomments’. With this, an individual can then add whatever CSS they want to the display of each item. Once I added my CSS, and added the function call to my sidebar, underneath my comments in the main page, I was done.

A modification to this would be the ability to delete an item, but they’ll roll off anyway, and I think it’s better to just do the link and walk away.

I also don’t have a separate syndication feed for the Pithy Bar. I think of my Pithy Bar as this weblog’s easter egg – goodies you get if you click through, or know what to look for. When you stop by to read one of my longer essays, you can then check out any new entries in the Pithy Bar.

For those WordPress 1.2 users, you can download a file containing an edited menu.php, the logfile.php, and a page to create the table (install-linklog.php) . These three you install in wp-admin, and then run the install program once to install the linklog table. If you copy in the menu.php file, do note you’ll copy over your version of menu.php, so use caution. You can also just edit your version of menu.php to add this highlighted entry.

The gzipped file also has the plug-in, my-linklog.php, that you’ll need to install in your plugin directory (wp-content/plugins/). When you install it, you’ll have to go into the Plugins tab of WordPress, find the plug-in titled, “My Linklog”, and then activate it.

If you decide to add this to your version of WordPress, as always, backup your files and database before installation.