Planet WordPress

As has been mentioned elsewhere, WordPress 2.0 is in beta. We’ve kept it low key so far, but we’re getting a pretty good testing turn out nonetheless. Several little bugs have been shaken out since the first beta. If you are feeling adventurous, try it and share your beta experience in the Beta Forum or on the Testers List. As always with unreleased versions, don’t use it on your live site just yet. If you do, make a backup and be ready to rollback.

To keep track of bug fixes going into 2.0, watch the timeline. We’re fixing bugs pretty briskly and releasing new 2.0 release candidates as we go.

Jacinta and I met Tom Raftery, Robert and Maryam Scoble this wet and cold morning to do the tourist thing in Blarney! Robert and Maryam were really unlucky with the weather today but that didn’t dampen their mood!
Want to see a picture? I’ve posted a photo of us after coming down from the castle.
Everyone is in good health and the narrow steps of the castle failed to deter us from getting to the top! Robert, Tom and Maryam all kissed the Blarney Stone so as they have now been given the gift of the gab, expect a lot more to be said by them!

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.

Matt finally reveals what perhaps a few people have known or suspected for quite a while. I’m working with him, Andy and Ryan on WordPress.com.
I am very very happy with what we’ve achieved so far and can’t wait to get cracking on the new features planned!

That does explain why I don’t post as often here. I’m too busy. I’ve got a text file full of links that I haven’t read, but I do manage to post one photo every day on my photoblog. That’s a great outlet for my photo creativity!
(Thanks Donal for that link correction!)

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.

Still on hiatus but wanted to post a little javascript (mainly for my future reference) I’ve used a few times in various applications.

One function will clear the “default” text in a field when the user clicks into it. The second function will replace the default text in the field if the field was left blank.

This goes inside the <head></head> tags:

<script type=”text/javascript”>
function clickclear(thisfield, defaulttext) {
if (thisfield.value == defaulttext) {
thisfield.value = “”;
}
}

function clickrecall(thisfield, defaulttext) {
if (thisfield.value == “”) {
thisfield.value = defaulttext;
}
}
</script>

Then you add the following onclick, onblur events to your field. (Shown in bold):

<input type=”text” name=”myfield” value=”default text” onclick=”clickclear(this, ‘default text’)” onblur=”clickrecall(this,’default text’)” />

Uses? a search field - your “default text” could give clues about what you can search for. ie “Enter keyword or item #”. Or it could display the format of the content you want from your user, ie. a date field with this as the default text “MM-DD-YYYY”.

Update 11/16/05 Updated script on the suggestion of Joan and Sunny.

Update 11/24/05 Here’s another neat way to do this without the “onclick” and “onblur” embedded in the input tag itself.

One of the big recent additions is the Persistent Object Cache. Objects such as pages, categories, options, and users are saved locally to disk so that WP doesn’t have to make a trip to the database. The object cache is completely pluggable, allowing hosts to tailor the cache to their particular usage and needs. Folks on the hackers and testers lists have been shaking out the bugs. The cache is looking pretty stable as of now.

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]

There is news of a worm which uses a vulnerability in the PHPXMLRPC libraries to spread a computer virus. Some articles are pointing to out-of-date information claiming that WordPress 1.5 is vulnerable. That is incorrect. WordPress 1.5 or higher is safe. Since the release of version 1.5, WordPress has used a completely different XML-RPC library, called IXR.

Older WP versions (1.2.x and earlier) are vulnerable, however. If for some reason you are still running a pre-1.5 version of WordPress, you should upgrade immediately to the latest version, WordPress 1.5.2 “Strayhorn”. If upgrading poses a problem for some reason, and if you don’t need pingbacks or blog client API functionality, simply delete the class-xmlrpc.php and class-xmlrpcs.php files from your installation’s wp-includes directory (but you really should upgrade).

Also if you ever come across something you feel might be a security problem in WordPress, please send a note to the special address we’ve set up for security purposes and we will address it as quickly as possible.

Just wanted to come on here and let you know that an article you first saw here (What does full server path mean) is being reproduced (with my permission) in Kevin Airgid’s book: Web Designers Success Guide.