Planet WordPress

I’ve got 4 installs of WordPress running various sites of mine, and I plan to migrate a few other sites to a WP backend at some point as well. This becomes a bit of a maintenence nightmare when I need to do upgrades or apply patches. Because of this, I’m considering doing an SVN checkout of WP on each site to make them easier to maintain.

The only issue is that I’ve got a few places in the WP core that I’ve customized for some of the sites - I’d potentially have to re-apply these patches and resolve any conflicts on each update. It wouldn’t be that big a deal though:

• alexking.org - I’d need to apply my patch to not require unique post slugs and I’d need to redo some of my site structure sincce I’ve got stuff hanging around from the b2 days.
• kingdesign.net - the unique post slugs issue and I hacked the search function to return “pages” as well as posts in the search results. If this isn’t standard in 2.0 (haven’t checked) I’d need to apply those changes.
• feedlounge.com - the new roles system should allow me to drop my hack to allow Scott and I to view and edit each other’s posts. Then it would just be a matter of the unique post slugs and search results.

I think that re-applying these patches to the latest from SVN would be easier in the long run than updating each install individually.

I guess I really want a process like this:

1. Update WP to latest from WP’s SVN repository
2. Check my mods and fix any issues
3. Test and commit to my respository
4. Update on production sites

I don’t know how to do this with SVN, though perhaps there is a way. Maybe the right way to do this is to get latest, make my changes, then create a patch. Then update the production sites to the latest from WP’s SVN and apply my patch.

When you work by yourself most of the time, the simplest parts of source control (branch, merge) are all you generally need. One thing I miss about working in a BigCo is absorbing this kind of knowledge by necessity without having to track it down.

I’m waiting for the inevitable .1 release before upgrading, but I’ve started testing WordPress 2.0. One of the first things I noticed was that the tooltips on the new rich text editor are just plain wrong for Mac users - we gots no “Alt” key, yo!

Mentally replace “Alt” with “Ctrl” and you’ll be fine. I guess we know what platform Matt and company develop on.

I created a bug in Trac and I added a task for myself to create a patch for this (if no one else has), but probably won’t get to it until after January 16th at the earliest.

WordPress does a pretty good job making things configurable just about everywhere - either via plugin or options in the admin side of things. There are a few exceptions however, and I was wondering if it would be reasonable to consider an semi-hidden group of settings similar to those you can access in Firefox via the about:config screen. In other words, settings that only the technical would access - with a “use at your own risk” disclaimer of sorts. To easily maintain overridden settings between upgrades, you could just set your override values in a plugin.

Something I’d like to propose for this type of setting is the ability to turn off the “each post slug must be unique” functionality. Yes, there is a plugin that sort of fixes this; however the “fix” occurs after the pingbacks and trackbacks have been sent. As a result, I’ve stopped sending pingbacks or trackbacks from my “Around the web” posts as the post link being sent is later “fixed” to remove the number.

I understand why it makes sense to have code in the WP core to “save the users from themselves”, but if I’ve set up my permalinks so that I know I won’t be creating collisions by using the same post slug - I want an easy way to accomodate this as well.

What do you think? Good idea? Not? I guess it’s too late to submit a patch for 2.0 anyway, but I wanted to put the idea out there.

UPDATE: To clarify, I’m talking about situations where an option might be confusing for casual users, or something (like requiring unique post slugs) is in place to protect people from shooting themselves in the foot, but a valid argument can be made in the mind of the developer implementing the feature to allow the alternate functionality. In these situations, the dev could simply add an option (to the vars.php file perhaps) and structure their code accordingly. If someone needs to flip around the way it works, they can simply override the variable in a plugin. It avoids adding upgrade complexity and clutter in the options screen, but still allows for clean override ability.

I’ve updated my WP Plugged In 1.5.2 release to include a few files that were missing from the original download. This also includes a version of WP Photos that is nearly a true plugin.

Download is available on my WordPress page.

WordPress seems to be moving towards a very nice 1.6 release, and I’ve started getting inquiries from people who would like me to run another theme competition when version 1.6¹ is released (likely sometime in early 2006). I think it would be fantastic to have another WordPress theme competition, but I’m not completely sure I’m the right person to host it.

The WP Style Competition (the first competition I hosted) was a rather straightforward affair. People submitted their CSS, I posted it on my site, judges voted - no big deal. The WP Theme Competition (the competition I hosted this year), was an entirely different deal. I’ve detailed this previously, so I won’t rehash it here. However, I would be remiss if I didn’t take that experience into account when trying to make a decision about hosting a competition next year.

In the first competition, there were 39 entries; in last year’s competition there were 135 entries - this was largely due to the growth of WordPress between the two competitions. In the past year, I believe WordPress has grown even more than it did during the previous year… how many entries should I expect in a competition next year? Any answer would be a guess, but I think that 200-250 wouldn’t be an unreasonable expectation.

One of the new features coming in WP 1.6 is a standardized way for themes to include their own custom functionality. I think people could do fantastic things with totally new presentation styles, maybe a litte AJAX goodness sprinkled in, etc. Unfortunately, all of this also brings with it another increase in the amount of time it takes to review each theme.

My position for the last competition is that if I am hosting the competition, and I’m making the themes available for download from my site, then I have a responsibility to make sure each theme doesn’t do anything malicious or stupid that could have negative consequences for WP users that download the themes. Also, since I’m putting the themes on my server - I have a vested interest in making sure they are “safe”.

As a result, I spent ~30 minutes reviewing and posting each theme. With the additional functionality coming in 1.6, I don’t think it’s unreasonable to expect that to grow to ~45 minutes/theme.

Since all of this is guestimated anyway, a realistic ballpark for time spent reviewing themes in the next competition is probably 150-250 hours. Add another good chunk of time publicising the competition, corresponding with sponsors and participants, answering questions, etc, and we’re looking at ~300 hours - rather conservatively.

As much as I’d like to, I know that I won’t be able to donate that much time to running a competition. So let’s look at some possible solutions.

1. Reduce the number of entries, which will reduce the amount of time needed for review. In the past, I’ve encouraged people to entry early and enter often. This doesn’t always translate to “quality” submissions - in fact I’ve read people’s blog posts lamenting that they think many of the themes are not up to snuff.

   There are a few ways to accomplish this, one is to put a cap on submissions per person (perhaps a 2 entries per person limit). This should have a side effect of improving the quality of the entries as well, as people will need to submit their best 2 themes. However I think this would only make a small dent in the overall number of entries.

   While Eric was in town last month, we talked a bit about hosting competitions. Eric is in the midst of hosting a big photo competition right now and we talked over a number of ideas. One of which was to charge an entry fee, maybe $10-15, per submission.

   At first, I really didn’t like this idea - in the first competitions I worked hard to have as few barriers to entry as possible. Adding an entry fee flies right in the face of that. However, after thinking it over, I think that it makes a certain amount of sense.

   Again it would likely reduce the overall number of entries, but result in a higher percentage of quality entries. I bet that we could even get a few sponsors to put up the entry fees for those who might have need assistance. Of course we’d have to have some great prizes as incentives to make the entry fee seem worthwhile for the participants. That brings us to our second option.

2. Bring in some money to pay for my time. There is no way I would expect to make my normal consulting rate, or even half of it - but even a quarter or a third of it would ceratinly help free up time to manage the compatition and review entries. In addition to the entry fees, I could also take a percentage of the prize money as a “hosting” fee (as suggested by several folks), and perhaps find some corporate sponsors as well.
3. Get help reviewing the themes. I’m skeptical as to how much help I would be able to recruit, particularly since there are currently 47 themes that need testing on the themes page right now. However, if I could get a couple of competent and reliable reviewers, it would be a wonderful.
4. Find someone else to run the competition. Perhaps the options mentioned above will fall short of allowing me (financially) to run the competition and/or people feel that charging an entry fee and/or diverting a percentage of the prize money is totally unacceptable. In that case, it may be best to hand the reins over to someone who has more free time and can manage the competition the same way I’ve run it for the last few years. I don’t believe this is the best option, but I’m also not so arrogant as to think I’m an indespensible part of this.

In the end, the best solution is likely a combination of all of these ideas. I wanted to get the conversation started early so there would be plenty of time to find a system we think would work.

The comments are open, I welcome your throughts and feedback.

1. And the competition would allow people to utilize the new functionality in 1.6 in their themes. [back]

A month and a half ago, I put up a group of untested WordPress themes hoping that people would help review them (so they could be added to the theme browser and main theme list). So far, only one person (thanks Trevor!) has reviewed any of the themes¹.

While I know it takes a bit of time to review each theme², I’m a bit disspointed that more themes haven’t been reviewed. If you or someone you know is a competent PHP programmer and use WordPress, consider taking 20 minutes to review a theme as a way of giving back to the community.

1. As a result, a few were removed and a few were added to the ‘final review’ list. [back]
2. Trust me, I know. I reviewed the 135 that are currently in the theme browser (and many of those multiple times as the authors kept sending in new versions). [back]

The WordPress theme browser is back up and running again after ~48 hours of downtime. For those who are curious, here is what happened:

Last week, I had to rewrite the theme switcher plugin because it was killing the server it was running on. The original theme switcher code was traversing every directory in each of the 135+ theme directories looking for themes, which basically keeps the disk working way too hard. I’ve basically cached that information now, so the poor other folks on one.textdrive.com won’t have to suffer because of it.

Right after that change was made, the cookie domain got messed up in the code. That was at exactly the same time the servers were being moved to the new TextDrive data center, so I wrote it off as a migration bug that would probably get fixed. When it didn’t get fixed, I dug further and found the problem (now fixed).

Now you can go on and get your fix.

UPDATE: Strange, it works fine if you click on the theme links on the page, which use the same URL as the theme browser code, but it doesn’t seem to want to work in the frameset. Unfortunately, I can’t get into the server right now, so I’m not able to debug or fix it.

UPDATE #2: Finally got in and was able to “fix” the problem - commented out a header call that has been there since the theme browser was first brought online. No idea why it needed to be changed now, but it seems to work again.

I’ve posted a list of untested WordPress themes that have been submitted to me for addition to my list, but that I don’t have time to code review before posting.

As I previously posted, there are a few things I’d like to have looked for in each theme. Once one person approves the theme, it will be moved to the Final Review list for one more review.

Once a theme has been code reviewed twice (by 2 different reviewers), it will be added to the list.

Have fun!

I know the WordPress theme browser isn’t working properly right now. I believe it is due to the data center changes taking place at TextDrive right now and it will be back soon.

I’ve updated my “plugged in” version of WordPress to 1.5.2. This includes the following additions to the standard WordPress install:

• WP Grins (new version, should validate now) - clickable smilies.
• WP Since Last Visit - shows new posts/comments since your last visist.
• WP Mobile - PDA friendly layout w/ auto-redirect.
• WP Photos (still not available separately) - add photos to blog posts.
• WP Unformatted - turn off default formatting on a per post basis.
• Theme Switcher - allow your visitors to pick their theme - works with all themes downloaded from my site.

Download it from my WordPress page.