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

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).

“PHP in WordPress themes must be GPL, artwork and CSS may be but are not required.
…
Even though graphics and CSS aren’t required to be GPL legally, the lack thereof is pretty limiting. Can you imagine WordPress without any CSS or JavaScript? So as before, we will only promote and host things on WordPress.org that are 100% GPL or compatible. To celebrate a few folks creating 100% GPL themes and providing support and other services around them, we have a new page listing GPL commercially supported themes.”

The legal opinion was provided by Software Freedom Law Center. Council James Vasile provided the findings and blogs at hackervisions.org . James also has posted about this on his own blog in the article “CMS Themes and the GPL“. As I commented there, my fear is:

“people read what they want to get out of it, and case law is the only thing that moves them.”

The legal finding and unchanged policy  are consistent with the intentions of the WordPress developer community and what has been promoted for the four years I’ve been involved.

Talking about licensing really is the suck. Matt’s article became necessary lately as some commercial theme developers have been very aggressive to WordPress community members, who have shared theme code as allowed by WordPress’s viral GPL v2 license.

It frustrates me when I read commercial theme developers complaining about people “stealing” their themes after the thousands of hours they have worked. They make no mention of the hundreds of thousands of hours others have worked on WordPress (counting on the  GPL protecting their freedoms ).

The incredibly exciting news is seeing the various commercially developed and supported themes embrace the GPL in the last 9 months. Theme collections like ThemeShaper (Thematic FrameWork), StudioPress (previously Revolution 2),  and WooThemes are all 100% GPL — those are just the ones I’m familar with, be sure to check out the theme offerings of the other commercially supported GPL themes.