WordPress 2.8 Beta 1 Released

While I was rolling around near comatose yesterday WordPress 2.8 beta 1 hit the streets. We plan to do a thorough review of this project on Thursday at the Ohio WordPress meetup here in Akron, Ohio. So, I figured it would would be a good time to run it officially here in The Code Cave.

The upgrade process is as simple as always. Unzip the file, copy it over the existing files, go to wp-admin upgrade and click continue. When the official release comes out, I plan upgrading my wp-upgrade script as I still think it is useful. Even though WordPress itself has upgrade abilities within it, the full file backup and database backup that my script does, still provides added benefit. So, I’ll keep it around a while longer.

As for WordPress 2.8, you don’t need to fear about learning a totally new system from scratch. There are a number of nice changes and tweaks, but the basic interface remains the same. There are a lot of changes for plugin developers and the like, but the everyday users will see some things like the new widget drop zone that makes it easy to make a widget inactive without loosing its settings. I’ll be testing over the next few weeks to see what I’d consider note worthy for a release post. I used to even do a line by line comparison, but I don’t know if I’ll don’t be returning to that. For now you can read about the changes here.

If there is any part of this upgrade that you definitely think we should cover at the Ohio WordPress Meetup, please let me know so that I don’t miss it!

WordPress Quick Tip: Fixing the number of comments per post

For various reasons, sometimes the number of comments shown under the title of the post may not match the number of actual comments displayed under the post.

Here is a simple SQL statement that will resolve the issue:

update `wp_posts` set comment_count = (select count(*) from wp_comments 
WHERE `comment_post_ID` = `ID` and comment_approved = '1')

You can use this to verify what would change and where your problems may lie:

SELECT ID, `post_title`, `comment_count`, 
    (select count(*) from `wp_comments` 
        WHERE (`comment_post_ID` = `ID`) and (`comment_approved` = '1')) as NewCC 
    FROM `wp_posts` 
    WHERE `comment_count` <> (select count(*) from `wp_comments` 
        WHERE (`comment_post_ID` = `ID`) and (`comment_approved` = '1'))

WordPress 2.6 – Causing waves on Mars: The XMLRPC controversy

WordPress 2.6 has been been trouble.  There’s been confusion about whether it would be out in July or August.  There was one date in the road map, and one in Trac.  On Sunday night, Charles Stricklin and I recorded episode 43 of The WordPress Podcast and I stuck with the August date that was in the Trac tool used for development. 

Then the next day Ryan Boren sent this reply to the WP Testers mailing list the next day:

On Mon, Jun 23, 2008 at 1:01 PM, Kirk M wrote:
> Do my eyes deceive me or am I seeing a due date of July 7th for the release
> of 2.6 with a fall back for July 14? Any reason for the releasing a month
> early? I’ve barely setup my test sites figuring I had a month to go ye;). 

[Ryan Boren Replied:]
There was some confusion because the roadmap had July and trac had
August.  Given that all of the features went into 2.6 early and that
its been running this whole time on wordpress.com and lots of our
personal blogs, a shorter beta seems doable.  I think we can launch
the beta cycle now, pound on it until the 7th and decide if it’s
ready.  If not,  pound it another week and decide of it’s ready.  I
merge 2.6 to wordpress.com almost daily and get tons of feedback in an
instant.  I’m pretty confident in being able to finish off 2.6 in a
few weeks.  We won’t be adding any more features to 2.6 so there’s no
need to linger for an extra month.  Also, a July 2.6 release allows us
to consider an early September 2.7 release that focuses on pulling in
some of the GSoC work.  That work would be too much to try to push
into an early August 2.6 release.

Ah, well you win some you lose some.  At least I wasn’t the only one who thought it would be August.

Since then a much more controversial debate has arisen.  Westi made the announcement that WordPress 2.6 would have the XMLRPC feature turned off.  XMLRPC is the technology that allows programs like Windows Live Writer, MarsEdit, ecto and other external blog editors use to communicate with your WordPress blog.  Here is what Westi had to say about it in his announcement:

WordPress 2.6 will be more secure out-of-the box including better support for running the admin over SSL and changes to disable the remote publishing protocols by default.

We have choosen to disable Atom Publishing Protocol and the variety of XML-RPC protocols by default as they expose a potential to be a security risk.  So from WordPress 2.6 onwards you will need to go into the Settings->Write page and enable them individually if you want to use them.

Mac software developer and MarsEdit creator Daniel Jalkut believes this to be a fundamentally wrong choice.  He’s said so on the wp-hackers list and on his website:

WordPress’s decision to shut off remote access by default is analogous to a bank offering unrestricted drive-through access to its cash machines, while requiring pedestrians to ring a bell and wait for a security guard to open the door to the machines.

Also worth considering: if a service is disabled by default for security considerations, what message does that send to people who choose to, or who are encouraged to turn the service back on? It sets up a perception of insecurity which may not even be warranted. If the remote publishing interfaces are insecure, they should be fixed, not merely disabled!

I think that’s somewhat misleading.  It makes people think that the switch has to be set  over and over again.  It is much more like, when you open a savings account, checking either the box that says you want an ATM Debit card and/or the box saying you want to access the account through the online site. Eliminating either of those options would make your money more secure.

I agree that there is an issue with people upgrading and finding that MarsEdit, Livewriter or whatever doesn’t work. That is easily solved by keeping the XML interface off by default on new blogs, but not changing the behaviour for upgrades.

But why not just “fix” the security issues?  Well the truth of the matter is that you can no more "fix" all security risk in xmlrpc than you can "fix" it in any software program.  It is a moving target.  New methods are thought of and software improvements introduce new avenues never thought of, even if there is a layer between the final interface and the database.  So even if WordPress was completely clean in 2.6, how can you prove that it is secure in 2.8 or 3.0.

Is xmlRPC secure in WordPress 3.0?  I don’t know it doesn’t exist yet.  But I do know if it is disabled for new blogs, that the new WordPress 3.0 blogs won’t face an XMLRPC security risk.

Tip Tuesday: Manipulating Graphics files for your blog

When working with graphics files on your blog, it is always smart to optimize their size for their targetted use. A simple corner picture does not need an original size of 8.1 mega pixels. On a windows machine, MS Paint can handle that sort of transformations, with a little pain and bloodshed. I’ve also written and posted here a console app to do the dynamic resizing. Gimp is awesome, but it is over kill.

I strongly encourage Windows users to check out Infranview. You might look at the site and say “Oh it is just a viewer”, but it is soooooo much more than that. Though it is the one of the best picture viewers out there, it also handles basic graphic manipulation better than most other software out there, even the pro stuff.

File resizing is very simple. However following their “It is trying to be simple for beginners and powerful for professionals.” goal, it allows you to, in the advanced menu, choose from various resampling methods in case the image just looks wrong when you resize it. Most programs use the 1 method the programmer preferred and you are stuck with it.

You can get it here:

and once you load the plugins from here:

(I prefer this mirror for downloads.)

You’ve got a powerful graphics manipulation tool that can even accept any photo shop 8bf plugins that you have lying around.

(BTW xnview is a infranview knock off, but it does have pocketPC and Smartphone support and works nicely as a viewer on those platforms)

Eliminating duplicate WordPress content in Google

If you are at WordCamp 2007, one of the best sessions was Google’s own Matt Cutts discussion on optimizing your WordPress blog. You can see the whole presentation over on John Pozadzides site’s One Man’s Blog. Here is the link. You can see in Matt’s Whitehat SEO tips for bloggers slide show that one of the things that WordPress “suffers from” is that you can reach the same data from multiple sources.

You can get to the same article by browsing by category, by day, month, year etc. etc. etc. Each time Google sees the same data repeated on your site again, it hurts your site a little bit more.

This bit of code will help fix it. It goes into the header part of your blog and will tell Google that it should ignore all of the pages that are not the orginal source of the article.

Here you go:
if (is_home() || is_single())
echo ““;
echo ““;

Upgrade to WordPress 2.2 or have your Admin PW stolen

OK It’s been a couple days now and this news is only spreading. If you haven’t heard already, there is an attack out there that allows the Admin PW to be compromised for any WordPress 2.1 and 2.0 blog. Only 2.2 and the yet unreleased version of 2.0 are safe and it will stay that way. The 2.1 is not a maintained version. So far, I’ve heard nothing about the plans to release a new 2.1. So at this point, for most people running 2.1, your only choice is to upgrade to 2.2.

I’ve stolen the admin PW of several 2.1 sites under my control and tested the sites of some of my friends to make sure they were safe even though they hadn’t upgraded.

There are two things that may make your 2.1 DB safe:

1. Your user named Admin is NOT user number 1.

2. Your database prefix is NOT wp_

If you want to upgrade safely and quickly, try my script.  The latest post about it is always at: http://www.thecodecave.com/EasyWPUpdate
If you want to see how we handled this at b5media, read here:
Guide to Disaster: How The Tech Team Handled WordPress Security Flaw

digg my story?

Feeling good on a Monday

Starting week number three at b5media and things are really starting to click.

I feel like I’ve settled in just a bit and I’m ready to get some real traction.  b5 is really growing and it’s great.  Over the last two weeks I’vehelped add a bunch of new sites to the network and we’ve got a number more coming in.

There’s a new theme that is being rolled out to a bunch of the blogs and I’ve helped with that, but due to the way it was implemented, we had some load problems as large common sections of html were being generated over and over again.  It was causing WAY more CPU usage than it needed to.

So, our excellent Linux guy Sean pointed me to a PECL module I’d not used before: memcached.

To quote http://en.wikipedia.org/wiki/Memcached:



From Wikipedia, the free encyclopedia

memcached is a general-purpose distributed memory caching system that was originally developed by Danga Interactive for LiveJournal, but is now used by many other sites. It is often used to speed up dynamic database-driven websites by caching data and objects in memory to reduce the amount the database needs to be read. Memcached is open source and released under a BSD license. It uses libevent.

Memcached lacks authentication and security features, meaning it should only be used on servers with a firewall set up appropriately. By default, memcached uses the port 11211.

Memcached’s APIs provide a giant hash table distributed across multiple machines. When the table is full, subsequent inserts cause older data to be purged in LRU order. Applications using memcached typically layer memcached requests and additions into code before falling back on a slower backing store, such as a database.

The system is used by several very large sites. Some well-known websites that use memcached are:[1]

It’s worked really well so far.  A few apache recompiles later and bam!  CPU load goes bye-bye.  With the initial partial rollout on a single channel we’ve tremendously reduced the load on the servers making 80 cache pulls per second instead of doing all of the db lookups and xml code generation.

I’m convinced!

I’m going to do some further implementation this morning we should be sitting sweet by EOD.

I’m also feeling good because I got the whole family up and did a morning workout in the new execise room I’ve setup in the garage.  I’ve also got Akaza hits nice and loud…

I’ve also got to send an email out to my Google Summer of Code student and we’ll get rolling on that this morning.  I’m looking forward to a good week.

Oh! and my pictures will be transfered by the end of the day so I can tell you all all about my toronto trip as I said I would two weeks ago…

Cheers all!