I've been using these two plugins for a little while, and they seem to generate interest in people when I mention them, so I have decided to release them and see what happens.

The first plugin, Auth Only, allows only logged-in users to access your blog. It also allows you to customize your login page by adding a login.php template to your theme. Using a login template will allow you to create a customized experience for your registered users.

You will need to use a plugin like the Role Manager to edit the capabilities of roles to grant view_site capability to whichever users or Roles should have permission to view your site.

The second plugin, Kill Preview, removes the preview frame from the Write Post page in the WordPress admin. Why is this useful? Well, if your site layout is particularly involved, you might not want to load the preview when you edit a post because it could cause delays in editing. Kill Preview prevents that frame from loading, speeding up your editing.

If you really need to see the preview, Kill Preview changes the Preview link on the Write page so that it opens the preview display in a new window. This will let you preview what your post looks like on demand, rather than loading it with every page edit.

I have a few other plugins that I use for myself that I haven't released for one reason or another. Perhaps I will consider releasing a few more of these if people find them handy.

MicroWiki is not a plugin.

It seems like I've been working on MicroWiki forever. There are many complex and nuanced emotions for me surrounding MicroWiki. I use it for nearly everything that I don't do with WordPress, so you can imagine how that might affect my feelings toward it.

At the same time, I've bashed the code to death. "Spindle" and "mutilate" are the words I would use to best describe the things I do routinely with MicroWiki after I get it installed somewhere. And every time I think "Hey, this is nearly ready for packaging!" I think of something else that it really should be doing better than it does, and I end up merging code from four different sites to get a revision with everything I've added.

In fact, I'll lay it out for you right here and now: You will not understand this code, even though it runs.

That said, if you want a wiki, maybe this is for you, and maybe it isn't.

MicroWiki 2.0 is not MicroWiki 1.3

I think that should be obvious, but I wanted to make clear right from the start that this incarnation of MicroWiki is not the same as the last one. There are a few significant differences.

For one, it doesn't use EzStatic to integrate with WordPress. For another, some of the wiki syntax is a bit different. (Yeah, I know, "Eek.") And it's a bit more flexible than last time.

There are a few cool things about MicroWiki. Let me list a few things that MicroWiki does for me that will probably cause me no end of support questions like, "Why can't I get MicroWiki to do what you said it would on your blog?"

MicroWiki integrates with WordPress. In this most recent pass, I switched around my philosophy as to how this would be done. "Integration" for our purposes means this: MicroWiki uses WordPress' database connection and user authentication, and has access to any functions that are usually defined when accessing a WordPress page.

So when you install MicroWiki and choose the "WordPress" User Registration option, it'll create its tables in your WordPress database, and it will allow only the users with "wiki_edit" capabilities to edit your wiki. And if you do something crazy like include a PHP file into one of your wiki pages, it will have access to all of the WordPress functions. Depending how you look at it, this could be easier than building a whole plugin to create a page.

MicroWiki has new rewriter functionality. Taking a cue from how WordPress manages rewriting (but not using WordPress' WP_Rewrite class), rewriting is handled internally when a URL is passed to it from a generic rewrite rule. Also having some more experience with mod_rewrite by this time, a sample .htaccess file comes along with the installer. Friendly URLs are now much easier to implement.

MicroWiki has no templates. This concept is a hard one to get across at first. Most wikis load a template file from disk, then take the content that you submitted to the database and insert it into that template. How do you edit the template? Well, you open up a text editor (outside the wiki) and edit the template. That's... um, convenient. Not.

MicroWiki uses a formatting tag to insert page content into a template that is stored in the database. You can edit the template inside the wiki. So if you don't like the way that the template is constructed, you can edit it inside the wiki without opening a text editor or downloading/uploading template file changes.

MicroWiki supports a content-type tag, too, so your CSS files aren't in some file on the server, either. They're in the wiki. You can edit them in the wiki.

You can specify a different "format" (that's what they're called in MicroWiki) for any page, just by including a macro, like {{format:myformat}}. Instead of displaying the page content of that page in the default format, MicroWiki will use the "Format:myformat" page as the page layout, inserting the content on that page wherever it finds the {{Special:pagecontent}} tag in the format page.

Yes, it's all very confusing, but if you're following along, I think you'll say, "Whoa, cool!" Either that or, "You're insane!"

MicroWiki has an image gallery built in. Wait. What? I'll say that again... MicroWiki has an image gallery built in. It's a sucky image gallery, and mostly it sucks because nobody ever knew it was there to give feedback for it. But it is. So what's the deal?

Well, the default editing page (have I mentioned that the editing page format can be edited, too?) has a frame at the bottom that lets you upload new image files. When you upload a file, it automatically inserts the macro tag necessary to display the uploaded image. You can choose some properties for the tag, like the alignment and whether you would like a thumbnail instead of the full-sized image. The image automatically links to a unique wiki page for that image, to which you can add new content.

In the frame, there is an option for selecting a gallery for the image. You can create new galleries via FTP simply by creating a new directory in the wiki's "images" directory, and then uploading a bunch of images.

How do you display a gallery? You add a macro that specifies the gallery name. MicroWiki displays thumbnails of all of the gallery images, and adds some fancy-ish (ok, it's not that fancy) that displays the image a little bigger when you click on a thumbnail. If you then click on the bigger image, you go directly to the dedicated image page.

That's assuming any of that actually works.

MicroWiki can include stuff. It might be difficult to convince you of the utility of this, but I'll give it a shot.

If the wiki configuration allows it, you can use a macro to include a php script's output at some point in the wiki page output. One handy example of what you can do with this is include a file that fetches and displays RSS news. If you put that in your wiki's sidebar, you can extend the functionality of the wiki significantly.

Moreover, because the wiki has already created all of the objects needed for database access and authentication, you don't have to code any of that stuff into your scripts. All you need to do is create the script with the functionality you want, save it near the wiki, then create a new wiki page that includes that file. Instant object access!

So where is this monstrosity? Hmm... Well, it's only 136kb, so it's a really small monster. But yeah.

Before you go off in an excited rush to get the thing, let me come clean a little (as if you couldn't tell):

This thing isn't tested for regular people to use.

What I mean is, it should install simply. It should run ok. I don't have any trouble with it. But I am not you. And seeing that I've had zero feedback on this version so far, that's hopefully where you can help out.

I've set up a forum for MicroWiki over at RedAlt. If you've got issues, drop them in the forum and I'll check them out. I'm not guaranteeing instantaneous (heck, any) response, but at least they'll be catalogged for when I get a moment to look. And if someone else has a working solution for your problem, that's the most likely place to find it.

So run along now.

Blicki might also interest you, if you're looking for post versioning and wiki-like linking within WordPress.

On the #wordpress channel on IRC, someone had requested some adjustments to the Countdown plugin that I wrote a while back, so I took a look at that project and decided to make a few small updates.

Countdown displays a list of dates to remember. You create a list of events, and Countdown outputs those events on your blog. The events can recur, so you can put in single dates like "06-04 Owen's Birthday (Observed)" and it will show that on the same day every year.

There are some more complex recurring settings, too, like the ever helpful:

1st sun apr Daylight Savings Starts

Note that this event recurs on the first Sunday of every April.

Previous users will recognize these settings from before, but I have added a few new little things to sweten up the plugin.

On small thing is a new set of date modifiers. You can now say:

2 days before 10-25

or:

the mon after 08-02

Which is especially useful when using it with the new Easter date:

the fri before easter Good Friday

But those are just the new date settings. In addition to those, there is a whole new administration panel for setting Countdown options.

On the configuration page, you can set the output format for events and dates, and also edit the event list.

Using the new formatting options, you could (for example) output the date as part of an image URL, and display a graphic instead of just the date. Or you could feed the date to some javascript code (that you create) to have it render your dates specially based on criteria of your choosing.

You can also use the formatting to change the dates for your locale, which was a big requested feature. You're no longer locked into the format provided with Countdown, and can now specify your own format using the PHP date() format characters.

One more interesting thing on the new admin panel is the "Add Event" form. It helps you create new events for the event list without having to remember the formatting. (Was it really that hard to learn, anyway?) Not all of the options are available there, but the most used ones are. Everything else is written up in the documentation on RedAlt.

Finally, the plugin has included support for the beta of Matt Read's Installer plugin. The Installer lets you install plugins directly from their zip files, and manages their files. You can easily remove plugins that you've installed with the Installer plugin.

Also - the main reason why I bring this up - the Installer will tell you if there are updates available for your plugins, and will automatically download and install them on a button click. Only plugins that include certain headers can provide this facility, and I have added these headers to Countdown. (This may be added to all of my plugins, assuming this format becomes well-accepted.)

If you're a plugin developer, you may want to check out the Installer and see about adding those headers to your own plugins. And instead of fretting about how to host an XMLRPC server to transmit your updates, check out the RedAlt Plugin Version Service, which can handle all that for you.

Note that the Installer and the Plugin Version Service are still young, some in Beta, and while they seem to be mostly working, there's still room for improvement. Feedback will be appreciated.

Have you noticed slowness when posting lately? I've seen more than a few recommendations on how to fix this issue, but no real fix for the fix.

WordPress 2.0 has moved the essential trackback/pingback/enclosure mechanics into a special script that gets loaded separately from when you publish a post. Instead of cycling through all of the pingbacks and trackbacks that it has queued before returning control to the browser (like in version 1.5), the publication process spawns a request for the special script and just continues normally.

The result is that you don't wait for pingbacks to finish when you publish, and they still get published properly, but in the background. So what's causing the big delay these days, if that mechanism is set up to prevent it?

There is something else that causes the publication process to wait on a response from an external site: Pinging.

When you publish a post, you can configure WordPress (via the Options>Writing page in the admin) to ping certain servers to notify them that you have published your post.

There are a number of services that respond to these pings, and by default WordPress uses Pingomatic. Pingomatic is a one-stop ping service -- You ping it, it pings many different services for you automatically. The trick is that you have to wait for Pingomatic to return before the Post page finishes publication.

Normally this isn't a problem. Pingomatic service has always been pretty fast. But in recent days, people have noticed that the ping process is really slowing things down. In some cases, you get the "White Screen of Death" after clicking Publish and waiting around for a while. Control never comes back to the admin page, and your copy of WordPress dies waiting for a response from the ping server.

I have seen a bunch of people come into the #wordpress IRC channel asking why their site now publishes slower with WordPress 2.0, now that they just installed it, than it did with WordPress 1.5, especially with the new trackback/pingback code in place that was supposed to eliminate that problem. The solution for every one of them has been to remove "rpc.pingomatic.com" from their ping list.

Take a look at the scatter graph of response times for Pingomatic over the past few days. At one point, these numbers were looking really good. And for a service that is growing as quickly as Pingomatic, even the response we're seeing here is worthy of respect. My server wouldn't handle it. But that's little comfort to me when I'm wondering if my post was successfully published and pings were sent as expected.

In fact, a look at the top and bottom twenty sites monitored by Grabperf now shows Pingomatic as 3rd from last place in performance.

I personally removed Pingomatic from the ping list of Asymptomatic and saw instantaneous publication after many WSoDs. But now what? If you remove Pingomatic from the ping list, there isn't usually anything left. If you still want your site to ping some places, what do you do?

Here's a list of RPC entry points for the sites that Pingomatic pings. If you replace rpc.pingomatic.com with this list, it should accomplish the same thing as Pingomatic:

http://rpc.weblogs.com/RPC2
http://ping.feedburner.com
http://api.feedster.com/ping.php
http://www.blogdigger.com/RPC2
http://api.moreover.com/RPC2
http://www.newsisfree.com/RPCCloud
http://ping.blo.gs/
http://www.syndic8.com/xmlrpc.php
http://api.my.yahoo.com/RPC2
http://ping.weblogalot.com/rpc.php (Currently shows a PHP error)
http://topicexchange.com/RPC2
http://rpc.technorati.com/rpc/ping
http://rpc.newsgator.com/ (Seems non-existant?)
http://xping.pubsub.com/ping/
http://www.blogstreet.com/xrbin/xmlrpc.cgi (Seems non-existant?)
http://rpc.icerocket.com:10080/

I had trouble locating working entry points for Weblogalot, Newsgator, and Blogstreet. If someone knows valid working URLs for those entry points (or better URLs for the ones I've published), please comment. Use these at your own risk!

There are some other lessons to take away from this experience, in addition to getting your post publication time down to something reasonable. First, don't ping a service more than once for the same post. Some of these services won't even accept more than one ping before they've spidered you (it seems that Tenchorati works this way, from what I've seen). If you do that, there's a good chance you'll be banned as a spammer. Currently, I'm not even sure how you would get yourself removed from such a spam list, but suffice to say that your updates won't go out like they used to.

For that reason alone, you should be very wary of what services you add to your ping configuration, especially if you are concerned about notifying the world of your publication. I advise strictly against adding those huge lists of ping sites directly to your ping site list, because not only could there could be duplicates, but many of the sites on those lists are special-purpose sites.

Special-pupose ping sites are sites that accept pings for blogs of certain topics. Primarily, they are oriented to specific geographic regions and languages. If you are an English blogger, and you ping a Japanese ping site, it's possible that you will be considered a spammer. This is generally a bad policy. It's always a good idea to check with the ping service you're going to use before adding it to your list.

Keep in mind - the more ping sites you add, the longer it will take to ping. If you know which sites are the most important ones to you for getting your publicity, use only those sites for a faster return. Do you even need to ping sites? If not, remove them all!

Hopefully there will be some update to Pingomatic or WordPress that will soon fix these delays.

Whew.

There has been a lot of turmoil on the WordPress hacker mailing list about features for the next version of WordPress. If you didn't get your chance to join the fun, you might want to read up on the craziness that people have suggested for improving WordPress before you start shooting off suggestions.

Today marks the first commit of the big new features, and it's a doozy. I say "doozy" not because it's a fantastic feature (oh, but it is), but because it's a big change. I'll explain it a little and maybe you'll see why it's so cool.

But you should know now, if this affects you - You might want to stop updating your site from SVN for a little while. Of course, if you do this via script, it might already be too late. Eek.

In WordPress 2.0.1, Posts and Pages are stored in the same table. This doesn't change with the latest code update, however the method for marking a database row as Post or Page has changed. Instead of one field to demark a row as one of "Published Post", "Draft Post", "Private Post", or "Page", we're getting two fields.

One field (type) says "This row is a Post/Page." The other field (status) says, "This row is a draft/private/published." What's the big deal? Well, Pages can now be in draft, and possibly even private.

Of course, this may not mean must to you if you don't have multiple authors or have a general need for draft status on your Pages. But if things go right, we may also get a new status setting, "future", which means that the post (or page!) is scheduled to be published in the future. This is a pretty big deal, because the main post query is a tad inefficient when selecting records with dates.

In the current version of WordPress, the main post query uses a date in the WHERE clause to limit the posts it will return to only those posts that were published prior to the current time. That sounds fine, but it doesn't allow caching tools for MySQL to do their jobs, since the query changes every time the time changes. If we knew in advance to eliminate an entire "type" of post from that query, the query would speed up significantly, potentially due to two things: Using a query cache would be more possible, and there would be no relative compare against a date, but a direct compare against a preset value.

All of this technical babble boils down to better performance. And everyone loves better performance.

This new changeset is just one of the big changes people on the hackers list have been plotting for WordPress. Primarily the discussion has focused on ideas that make WordPress easier to use, faster and more reliable, and less likely to generate support requests. What actual new functionality will appear in the next version remains to be seen.

One thing of keen interest to me is the recent topic of including a Firefox-like plugin update system. One of the big issues for 2.0 upgrades was seen by people who left plugins installed from their 1.5 installation when upgrading. If the plugin was incompatible, it was typical to see a white screen or some unhelpful errors, and there was no useful information about how to fix it. The next version of WordPress should include (if we follow through with what is currently being planned on the mailing list) a method to eliminate that issue. How exciting!

I can't wait to see what other stuff is planned for the next version.