I’ve enjoyed not being able to keep up at all.

The sprint is on to feature freeze!

There’s going to be a patch sprint of sorts for 3.0 this week. Please grab a ticket, triage, patch or test:http://core.trac.wordpress.org/report/32. The feature freeze is March 1, so everything still on that report in 7 days from now will be punted to a future release.

There are a few incomplete tasks out there that need to get done to finish implementing new features (both small ones on that report, and the major 3.0 features). If you’re interested in helping but aren’t sure where you can, venture over to #wordpress-dev.

Andrew Nacin on wpdevel, Feb 22th, 2010

Jane Wells puts up a “Patches Welcome” sign on a “a handful of small UI enhancement tickets that are low priority for the hardcore devs, but that I’d still like to see make it into 3.0.” Jane will “try to post a couple of pet tickets each day throughout the sprint week that is coming up.”

Better, stronger, faster blog network creation and management will be huge!

Mostly I can’t wait for the twenty ten theme, and the slow death of the (poorly) justified text that may have been the Kubrick themes only shortcoming.

PS. Emphasis above and below (bold) is all mine.

PPS. WordPress 3 will look so good in the title of the next technical book you write

Wednesday, Feb 23, 2010 Update: Jane has posted “Menus, the Merge, and a Patch Sprint!“ with details on the WordPress Development Blog, including the tidbit that WordPress 3 will have much improved menu management.

The WordPress Foundation is a charitable organization founded by Matt Mullenweg to further the mission of the WordPress open source project: to democratize publishing through Open Source, GPL software.

The point of the foundation is to ensure free access, in perpetuity, to the projects we support. People and businesses may come and go, so it is important to ensure that the source code for these projects will survive beyond the current contributor base, that we may create a stable platform for web publishing for generations to come. As part of this mission, the Foundation will be responsible for protecting the WordPress, WordCamp, and related trademarks. A 501(c)3 non-profit organization, the WordPress Foundation will also pursue a charter to educate the public about WordPress and related open source software.

We hope to gather broad community support to make sure we can continue to serve the public good through freely accessible software.

About Web page, WordPress Foundation

There are already a lot of great comments on the welcome post “Getting off the ground“. Here is a one of the many juicy comments made by Matt in response to a question posted there:

Sure, as a quick summary: [Wordpress.com and the Wordpress Foundation] completely separate, but share a similar name and my involvement. One is for-profit, the other non-profit. They both have similar goals in terms, but the Foundation can take a long-term multi-decade approach to solving these problems without regard for short term profit, market conditions, or shareholders. I’ve always had a vision for two simultaneous approaches to the WordPress way, the heart and the mind, but it’s just now coming together.

The combination of the elegant and versatile WordPress and the ground breaking Kubrick made that possible, turning the democratization of publishing from an idealized concept into a concrete reality.
Tina Daunt, “The Secret History of Kubrick, the Blog Theme That Changed the Internet“, Huffington Post, Jan 8th, 2010

“Free and open source from the roots up. “Open source” can be much more than a development methodology. For me, it also constitutes a world view that upends institutionalized notions of competitive advantage that saw their apex in the twentieth century.”

Excerpt from Paul Kim’s “Why I Joined Automattic” published September 9, 2009.

Freedom by Abnel Gonzalez, CC by, Flickr Hosted

I’ve come to think of the people who build open source and free culture into their businesses as not only having the creativity and resolve to put their values at the core of their businesses, but also the foresight and humility to know that the future is always built on the past, that the future is outside of their control, but possibly not their contribution.

This is one of the main reasons I so enjoy working with Matt Mullenweg, Toni Schneider, the rest of the Automattic crew, and the WordPress.com VIPs and WordPress businesses I get to so regularly interact with. I’m ecstatic that Paul has joined us!

WordPress is a community of hundreds of people that read the code every day, audit it, update it, and care enough about keeping your blog safe that we do things like release updates weeks apart from each other even though it makes us look bad, because updating is going to keep your blog safe from the bad guys. I’m not clairvoyant and I can’t predict what schemes spammers, hackers, crackers, and tricksters will come up with with in the future to harm your blog, but I do know for certain that as long as WordPress is around we’ll do everything in our power to make sure the software is safe. We’ve already made upgrading core and plugins a one-click procedure. If we find something broken, we’ll release a fix. Please upgrade, it’s the only way we can help each other.

Matt Mullenweg, September 5, 2009, “How to Keep WordPress Secure“,

Do read the rest of the potent post — articulate, insightful, and honest.

Consider this simple example:
<link rel="stylesheet" href="http://example.com/wp-content/themes/default/style-ie.css" type="text/css" media="screen" />

If as part of a migration or server change, WordPress ends up in a sub-directory this will break.

For file system based access, if I see ABSPATH . '/wp-content/ … things are likely OK, though if WP_CONTENT_DIR or similar are changed, this will also break.

I’m tempted to use the constant STYLESHEETPATH or is it TEMPLATEPATH? But, those are static variables initialized early in the WordPress run.

I’ve been meaning to write this article for a while. Serendipitously, when I went to write a first draft of it, Mark Jaquith’s had just published “Force CSS changes to “go live” immediately“.

In the comments, demetris suggests using STYLESHEETPATH, but Will Norris quickly points out “sure, but you still have the same problem of bypassing any plugins that may be using the ’stylesheet_directory’ hook to pull the stylesheet from some place else entirely.”

Mark’s solution beautiful illustrates how to get the the URL location of the theme’s files and also directly the URL for the main stylesheet style.css:

<link rel="stylesheet" href="<?php bloginfo('stylesheet_url'); echo '?' . filemtime( get_stylesheet_directory() . '/style.css'); ?>" type="text/css" media="screen, projection" />

What Will describes is exactly what WordPress.com depends on. We have a similar, but much more complex solution to deal with the CSS in the content delivery network (CDN) going stale on updates, and also some web browser’s with their funky caches not keeping up. Our solution is both for WordPress’s front end and dashboard (also dealing with the various ways CSS can be called or @imported).

I do have one niggle about Mark’s solution, and it’s the same with most WordPress code out there, the use of bloginfo(). Strings within strings within strings within strings give me headache, so to ease readability and make it more verbose replace:

bloginfo('stylesheet_url'); with
echo get_stylesheet_uri();

bloginfo('stylesheet_directory'); with
echo get_stylesheet_directory_uri();

If you look up in the codex get_stylesheet_directory() you’ll see that would be the file system path, which is confusing given the behavior of bloginfo('stylesheet_directory'); returning the URL. This presents another reason why I favor the consistency of always using the specific getter function calls. Also, when I’m using bloginfo() calls, I have a tendency to get in a mind set where I think I’m directly retrieving the option in the database (accessing directly the info shown in wp-admin/options.php). By using the specific getter function, I remember that there are hooks (actions, filters) that might be triggered.

Some of the other areas, I see wp-content is in CSS style sheets themselves. Relative paths are almost always the correct solution.

Far more painful for me are the plugins that assume where plugins are, because this can take quite a bit of debugging to unwind the assumptions.

That is a topic for me to postulate on another day. Will has written the very relevant “WordPress Plugin Pet Peeve #2: Direct Calls to Plugin Files“. Duane Storey has taken a crack at a “WordPress Plugin Checker“  for these and other common problems (which I’m certain he would enjoy feedback on).