I worked some more on the patch we had for #19810. The original patch had features that exceeded our original scope (namely: the ability to bulk-add users). I removed that, cleaned up the JS a bit, and we now have a patch that can probably go in and be iterated.
http://core.trac.wordpress.org/attachment/ticket/19810/19810.5.patch
Next up is making it work in the add-user-to-blog interface in the Network Admin.
As the WordPress core team is in the middle of an in-person meetup, we’ll be skipping the IRC dev chat this week. We’ll be collecting our notes throughout each day of the meetup and posting a summary the following day.
Timelines and assignments will be decided next week, but in the meantime, here’s what WordPress 3.2 is looking like:
> Distraction Free Writing
Yep, we were looking at that too, for some inspiration.
Awesome
its pretty cool, but i think they are giving too many options, something like informationarchitects.jp’s writer for the iPad, seems like a more metaphorically appropriate, smashing called it “effective”
its comes down to being strict and deciding what is truly important for writing
Agreed. And what limited UI there is should be out of mind (even fade away as you type).
Having downloaded and had a play with Zen – yes it is lovely but can be a distraction in itself, I feel. Agree with vachi that there are too many options. #justsaying
I think this is pretty neat, but should remain as a plugin, why bulkify the admin, when the whole premise of WordPress is it’s expandability via plugins?
There’s also already a full-screen mode which comes pretty close to this.
The point is to replace the full-screen mode. It has good intentions, but isn’t implemented well.
Will Quickpress be a focus in 3.2? On the P2 dev forums there was discussion of adopting and extenduing quickpress for use with P2 and any other theme that wanted to use it.
We’ve not discussed that. I’d rather be conservative in 3.2 and get us back on track with on-time, focused releases.
Waiting for it. WordPress changed my life
You are spoiling us! Exciting stuff on its way – thank you all – we are not worthy. Now to go check that everyone has the required levels of PHP and MySQL.
Yay! Hopefully this help me put a final nail in the coffin for the one PHP4 server I am co-managing.
You don’t need to wait for WordPress 3.2 to upgrade to PHP5. Releases of WordPress have worked just fine on PHP5 for quite some time.
I’m glad you made that comment, it could help others, but you miss understood. It’s not entirely my server, but an emergency server in a remote datacenter that we should have moved to more economical cloud hosting years ago.
Is there a reason we don’t go a bit higher than 5.2.4 for PHP? The versions shipping in the most used server distros do allow us to go a bit higher:
CentOS 5.5: PHP 5.1.6, MySQL 5.0.77
Debian Etch: PHP 5.2.0, MySQL 5.0.32
Debian Lenny: PHP 5.2.6, MySQL 5.0.51a
Debian Squeeze: PHP 5.3.3, MySQL 5.1.49
Red Hat 4.8: PHP 4.3.9, MySQL 4.1.22
Red Hat 5.6: PHP 5.1.6, MySQL 5.0.77
Red Hat 6.0: PHP 5.3.2, MySQL 5.1.47
Ubuntu 10.04 LTS: PHP 5.3.2, MySQL 5.1.41
We settled for 5.2.4 based on usage. That’s where the huge PHP 5.x “break” happens. 5.3 is a no-go. It’s also what Drupal and Joomla require.
Based on usage makes sense. Thanks for the answer.
Is there not a potential security issue, in that php.net do not support the 5.2 series any more?
Is it forseeable that while WP 3.2 can move to PHP 5.2.4, WP 3.3 / 3.4 can be moved to PHP 5.3+ ?
Not at this time. Less than 6% of WordPress installs are running PHP 5.3.
Where is that 6% figure from? Some call-home feature from WP installs on update checks?
If the problem is in fact the hosts themselves using unsupported version of PHP, do Matt’s / Automattic’s recent connections made through JetPack integration not have any influence in persuading the big hosts to bump their distributions up?
“the hosts themselves using unsupported version of PHP”
That word “unsupported”. It does not mean what you think it means.
Developers might follow the ivory tower pronouncements from php.net, but ops (for the most part) really only care about what their distribution vendor is doing. And it’s ops who by definition decide what is and isn’t supported.
For example, Ubuntu 6.06 LTS is still supported by the vendor and contains both PHP 4.4.2 and PHP 5.1.2.
RHEL 4 is still supported by the vendor (and will be for another year) and contains PHP 4.3.9 (and no PHP 5 at all).
@Rob – What does “supported” mean in this case? Have Canonical or Redhat backported PHP 5.x patches? Have they rolled their own release? Have they picked up core PHP development?
One of the first rule of Ops is to update your software. PHP 4.x has been formally dead for nearly 3 years. If someone is still running it.. oh well. Odds are they’re still using WordPress 1.x and Windows 95 with IE6.
“Have Canonical or Redhat backported PHP 5.x patches?”
Where security- or stability-related, yes. This is what distributions do.
“Have they rolled their own release?”
Yes. This is what distributions do. Feel free to open up a .src.rpm and have a look. The CentOS mirror at http://mirror.centos.org/centos/4/updates/SRPMS/ would be a good start.
“Have they picked up core PHP development?”
No. This is not what distributions do.
“One of the first rule of Ops is to update your software.”
But not to keep blindly updating to the latest-and-greatest-and-possibly-broken-or-incompatible version. (Particularly for PHP which has a terrible track record of changing a few APIs for no apparent reason with every single patch release.)
“PHP 4.x has been formally dead for nearly 3 years.”
Ivory tower pronouncements from php.net are ivory tower pronouncements.
If there’s anyone to call out php.net for ivory tower pronouncements, it’d be Keith. Make a point about PHP 5.3, sure — but not PHP 4, that’s pretty ridiculous. You’re barking up the wrong tree, I think.
re RHEL4 / Ubuntu 6.06 – just because a product is supported, doesn’t mean they should continue to use it if newer (including LTS in the case of Ubuntu) versions are available, which, I assume, include newer versions of PHP.
Clearly it’s a business decision for hosts – organising their clients such that those who want / need to stay on older versions can do, while taking on the cost of updating distributions on servers (or even possibly just PHP itself) and supporting their clients through the transition.
Without incentives to update, it’s a catch-22 – popular projects won’t update without the usage existing, and hosts won’t feel the need to update for a competitive advantage in being able to host the popular projects that require 5.3, despite it being released 21 months ago.
My query, was that if WP is powering ~10% of the world’s websites, the WP community (perhaps with the communities from Drupal, Joomla, and non-CMS projects like Zend Framework 2 and Doctrine 2 which already require PHP 5.3) to push the big hosts to make the jump to PHP 5.3, then all the communities would be able to make use of the technologies sooner, than if we sat back and were forced to support whatever legacy versions hosts and distrubution makers decided.
If 6% is accurate, I agree that requiring 5.3 is ridiculous, but I’d like to see the WP community lead the way in pushing for increased uptake for it by hosts.
I would agree with the following:
“If 6% is accurate, I agree that requiring 5.3 is ridiculous, but I’d like to see the WP community lead the way in pushing for increased uptake for it by hosts.”
“Make a point about PHP 5.3, sure — but not PHP 4, that’s pretty ridiculous.”
Yeah. My point wasn’t so much that PHP 4 is alive and well (it is alive but certainly not very well), but that it isn’t php.net who get to decide what’s dead. If you feel uncomfortable with using PHP 4 as an example, feel free to pretend that I wrote PHP 5.1 (dropped by php.net, but will continue to be supported by RHEL 5 until 2014.)
“just because a product is supported, doesn’t mean they should continue to use it if newer (including LTS in the case of Ubuntu) versions are available, which, I assume, include newer versions of PHP.”
On the contrary, if a product is still supported, that is an extremely good reason to continue to use it, regardless of whether an upgrade is available. In large shops, systems are upgraded because it is necessary, not because it is possible. (Note: just because it is possible does not make it necessary.)
Specifically with regard to PHP, consider how much custom code broke when magic_quotes started to default to off. (It could argued that code was broken, but that would be wrong. If the code always produced correct output for all possible input, then it worked. And the upgrade just broke it.)
Also remember the PHP developers’ strange fondness for changing a few APIs for no apparent reason with every single patch patch release.
Sure, these upgrades probably won’t break production code. But they very easily might. And the more custom code you have, the more likely it is that it will break, and the harder and more expensive it becomes and the longer it takes to fix.
So if the upgrade isn’t actually required, why do it at all? There’s no upside, and a massive possible downside.
As of last November, the last of the major distros went to PHP 5.3.x as their base install. That should help adoption but it’s still nowhere close to mainstream. I’m guessing the 5.3 numbers will grow nicely this year and become common next year.
“As of last November, the last of the major distros went to PHP 5.3.x as their base install.”
Except CentOS. And not supporting CentOS would be a bit embarrassing.
Less than 6% of WP installs are on PHP 5.3. We’re likely several years away from being able to require it.
Not all providers always run the latest OS version
Great looking roadmap. I actually wouldn’t mind several more releases like this one to allow the smaller sister projects to catch up.
It’s very existing to see WP keep working on performance and writing experience.
Looking forward to the release!
Any changes planned for multisite? This seems like an off the wall question to ask but will there ever be any plans to add an optional python API stream for those of us running it along side php on our servers and looking to build plugins that take advantage of some of the newer Google API and cloud storage features. This plan looks great…
Multisite enhancements and bugfixes will probably go in. Nothing planned as big as the Python API you mentioned!
Thanks Mark, I’ve been wanting to create a Python Strings plugin that lets me call python function calls from the WordPress SQL DB but I wasn’t sure if this was something you guys already had planned, if I make something useful I’ll shoot it your way but I just wanted to make sure I wasn’t working on something you guys already had on the table.
Activation/Deactivation/Install/Uninstall Hooks for Themes, as per their analogous Plugin hooks? (Pretty pretty please?!? 
)
I’m pretty sure this would get in, if there was a patch for it.
I can try; I’m not sure I have the chops for something like this.
If you do come up with something, attach it to #14955
Okay then; it’s a project for me, unless someone beats me to the punch!
i was working on his than dropped, will look for my code and share, thanks for reminding
@chip – First, start off by writing a short comment describing each and every step. Then don’t worry about the overall code, but just try to implement the individual lines. Even if you can’t do all of it, someone else will be able to follow your intent and more easily give you a hand.
Or you may find out the little pieces are feasible. 
Is an overhaul of media handling in the works for 3.2, or is it going to be pushed a bit?
http://codex.wordpress.org/GSoC2011.#Media_.280.29
Not for 3.2.
Gallery needs much help! Otherwise, I’m in favor of 3.2 faster and lighter. Thanks!
can someone make JQuery default on Google CDN?
There’s a plugin for that. Not considering it for WP core right now.
I’d like to mention that this is not a good idea and people having plugins or themes that do this is also not a good idea. Typically, there are slight issues with specific versions of jQuery. Sometimes these issues need to be worked around with specific changes to the JS code.
As WordPress does things right now, a plugin or theme dev can look at the WordPress version, know the jQuery version (as long as no one else has changed it), and load the appropriate code to make sure that problems are avoided. If the jQuery version is out of sync with the WordPress version, this can no longer work and increases the likelihood of JS code breaking unexpectedly due to unknown jQuery versions being run.
monkey patching standard libs is not a good idea.
Loving the EOL for IE 6… dieeee!!
What about new 2011 Theme ? Is that going to happend ?
We’re discussing that. Nothing to announce for sure at this point.
And what about a complete new ‘Media Library’ with file browser and folder tree ?
Not this release.
Distraction-free writing. Can’t wait.
I’m sure there are probably a dozen others out there too, but I added a “distraction free writing” feature to my Fluency Admin plugin that was updated a couple of weeks ago.
eg. http://www.flickr.com/photos/deanjrobinson/5481489470/
Thanks for sharing! We’re looking at a bunch of things for inspiration. Will play around with the latest Fluency.
ooh the changed-files-only upgrades would be awesome; wanting that for some time now. scanning would be cool too. Speed = yay, php5x = yay,
My only wish is that the default theme is not updated when core is updated, since we have the ability to update themes separately, leave the theme alone and let us update it separately. Other than that, great job. I love WordPress.
That was actually part of the plan. Forgot to add that in the list! Good call.
I’m excited by this release… it’s good to have a pause every-so-often from throwing new features at a product and concentrate on speed improvements and having a general “housekeep”.
I’d love there (soon) to be a “small niggles” release too – no big changes, but lots of bug fixes and general tidying up of minor issues.
Just in case I don’t make it to the meeting on Wednesday, I would like to continue the work on advanced taxonomy and meta queries, specifically improving the SQL and fixing some API issues.
I believe there has to be a taxonomy table for metadata.
Will dropping re-install of Akismet and Hello Dolly on core upgrade be included in 3.2?
More speed is always a good thing. Will database calls and php performance be looked at? My web host tells me lots of database calls and the php system calls cause most of the system load in a shared hosting environment.
At the moment front side performance seems ok with an optimized theme, but the admin side always feels kinda sluggish, even with different web hosts.
PHP Performance is going to be looked at. We can probably do better at only loading the things that are needed for a specific admin page. And we’ll continue to identify admin screens that could be sped up or need help scaling.
Sounds like awesome news!
Will the options API improvement will be part of 3.2?
http://core.trac.wordpress.org/ticket/14365
I’d be fine with that. Seems like a small enhancement. There will be enhancements and bug fixes not mentioned in this post. This post is about things that could be called features.
I like the focus. WordPress has gotten a bit bloaty over the years and I don’t use many of the newer features for a regular blog, so anything that increases speed and reduces size is welcome.
This will also make life for plugin developers easier. since there is less PHP hassle to take care of
Just wondering if implementing core plugins (like drupal) will help it become lighter…
Give us core plug-ins, finally! For more speed AND less server load!
yes, please start now and move topics in core plugins
I don’t think the general idea of core plugins has anything to do with speed or server load.
If you folks are working on the post editor, can you please please please fix the post editor warning screen when multiple users accidentally begin working on the same article. It’s been a bug since 3.0. – http://wordpress.org/support/topic/text-editor-warning-issue-with-wp-30?replies=6
First I’m hearing of that. I’ve commented on the thread.
It was earlier told that removing the /blog slug on the main blog in WPMS would be addressed in a future release. Any plans in 3.2?
Likely no. Nothing major for multisite is planned for 3.2, and global permalink detection would be a pretty big enhancement. (Needs a patch first before consideration.)
Also my improvments or wishes?
Exclude functions (example: revisons) to Core plugins
Standardize how plugins deal with settings and navigation
Better localization support, to many memory and use php-standard functions for localization (this reduce the memory with PHP5)
Page speed optimizaton (filter rewrite rules)
n to n relationship for attachments
Make the admin more easily themable
Move Akismet and Hello Dolly out of the core package; not only from upgrades
Kill all inline-css-styles
Regarding IE6 EOL, Microsoft is on IE6 Countdown ( http://www.ie6countdown.com/ ). It _could_ be an option to BrowseHappy (it’s from Microsoft; but it cuts out other browsers)
BrowseHappy.com is a WordPress (and Matt) creation, so the goal would be to update that. IE7 isn’t modern either.
China has 34% IE6 usage?!?! does this mean WP 3.2 will become closed to the Chinese internet userbase?
Absolutely not. We’re not blocking IE6, we’re just not investing time in supporting it specifically. They already get a sub-par experience, so that won’t really be a change.
I don’t want to send IE6 users to a site where Microsoft advocates IE8, a old and terrible browser. Yes, I said IE8. Windows XP users can’t run IE9. And even IE9 is about 2 years behind the latest stable versions of Chrome, Safari, Firefox, and Opera.
“If your existing WordPress installation has been set up for more than a month, due to issues with existing permalinks. (This problem will be fixed in a future version. See Switching between subdomains and subfolders for more information.) ” http://codex.wordpress.org/Create_A_Network
Is there a plan to take care of this in 3.2?
Probably not — no major plans for changes to multisite in 3.2. This limitation is circumventable, but the point of the limitation is to avoid shooting oneself in the foot, as the main site’s links will break in a subfolder setup.
Must try to get improved comment loading in as a patch.
Not sure what you mean by this.
I know this probably isn’t the right place to ask this but the current way Muttisite works (with a set of tables per blog) is horrible. I know that its down to how multisite was created and to avoid major changes in the WP core files but now they’ve been merged are there any plans to move away from a set of tables per blog and towards a blog_id column on a single set of tables? I appreciate that it would mean a large amount of scary work for people with large sites but from a DB point of view it would make more sense.
No plans. Never, would be a safe bet. The sharded nature was by design. WordPress can host anywhere from one site to 18 million sites (WordPress.com). This wouldn’t be possible if not for sharding.
Oh please fix the memory issue we have, that memory is not configurable because of the 256MB limit in admin: #13847
I’m less interested in new features (e.g., editor) than in stability, stability, stability and speed of the engine. The improved update is good. Making sure plugins keep functioning is critical. Don’t break things. Every time there is a “drop of support” for PHP older versions, etc I worry because is my web host going to update in time? This slows down the updating cycle.
Seriously depressed that once again the media manager is being pushed to the sidelines. It may just be me, but every time we have brought up this topic over the past 2 years, we are told to wait for the next release. In fact during the 3.1 discussion it was made very clear to everyone that 3.2 would focus on media….
Sad day…
If it something you want to tackle then starting with a plugin that would improve the media experience would be a good way to develop and test new approaches, especially if current core focus is else where.
From the perspective of making things ‘faster and lighter’, it would be really good to have a nicer way of mapping multisite blogs into the blogs.dir directory, so that web servers can easily be configured to cache media files (rather than have to hit PHP every time). Or have I missed a trick?
If you are thinking in a better UI for writing, you can do something that hides or show the only relevant fields when choosing a given “post format”, with an API that can be used for other stuff.
Will the upgrades improvements roll over to the way plugins / themes are upgraded too, or is this ONLY for when upgrading WP Core?
In the case of the partial upgrades (Zip archive containing only changed files between versions) for now that’ll be limited to core, It may be offered in future for plugins but Core benefits from it much more as it’s a 3MB zip containing 99% unchanged files (in the case of .1-.2, .2-.3 etc) whereas most plugins will be sub-100K.
The FTP optimizations will apply to all Upgrader actions (Core upgrades, Core Reinstalls, Theme/Plugin Upgrades & Installs).
Thanks for the clarification. Hopefully in the future offering that feature for plugins or making it hookable so it could be enabled by plugins would be beneficial for larger ones.
Distraction free writing? How is WordPress going to keep the kids quiet, the phone from ringing and the dogs from wanting to be walked? Looking forward to the release. Thanks to everyone who works so hard to make things so easy.
Still waiting for core plugins.. nag, nag.
Make the API for adding fields to the Quick edit more intuitive. Related: http://core.trac.wordpress.org/ticket/16392
How do you actually measure “faster”? Is there some kind of benchmark suite or tests that verify this? I’m getting a bit tired of reading “it feels faster” and would prefer seing a profile output from xdebug or something. mutter mutter.
The new wordpress 3.2 is very improved and feels much faster than earlier. I simply love the new fullscreen mode / zen mode.
Great work on WP 3.2 the speed are UI changes are excellent.
We done goofed. One of the security fixes for WordPress 3.0.5 was overzealous. It fixed the issue, but it also stripped advanced HTML (on display, not save, thankfully) from comments by people with the unfiltered_html capability. It’s sort of a rare bug — doesn’t apply to multisite installs, and not many people know that Editors and Administrators on single WP installs can use images etc in comments, so we don’t think it warrants another release. People have WordPress 3.0 fatigue already. And 3.1 is so close I can taste it (takes like pork BBQ, natch). But it is still annoying.
As Nacin mentioned, a hotfix for this issue went into Akismet 2.5.3. Akismet is very popular, and just happened to be planning an update today. We figured that would be an easy way to fix the issue for some WordPress users today. The Akismet team at Automattic was kind enough to oblige.
But this wasn’t the first non-critical-but-sort-of-annoying bug in WordPress, and it won’t be the last. So I created a plugin: Hotfix. It fixes the 3.0.5 bug, but I intend for it to fix selected future bugs as well. If we can get this installed on a bunch of sites, it could be a very handy way to push fixes out to people faster than we can with WordPress core releases.
If we can get this installed on a bunch of sites, it could be a very handy way to push fixes out to people faster than we can with WordPress core releases.
Bundle it and pre-activate it?
I think that would confuse the hell out of average joes. Hotfix vs update?? zomg!!1
Bundling it seems reasonable, as long as it won’t be continually reinstalled (i.e. follows the behavior that Hello Dolly and Akismet will exhibit in the somewhat near future).
The Akismet avenue is very practical and is a nifty fix, but also it feels rather inappropriate. I’d rather have just seen the plugin made public for those few who need unfiltered html comments before 3.0.6 is released (if ever).
Well really, me personally, I’d rather see Akismet 3.5.3 bundled with WordPress 3.0.6 because people are still trying to figure out how to update Akismet after these upgrades anyway. But I understand rapid fire updates are unpopular with people.
I’ve got to agree that it feels inappropriate and I just really hope that bundling fix’s with Akismet or Hello Dolly or whatever… never becomes normal practice. Don’t get me wrong, I love Akismet but like Hello Dolly it, IMHO, it shouldn’t be bundled with core updates.
I am intrigued by Mark’s hotfix plug-in. It would seem, at least at first look, to make a lot of sense to build into core.
And there’s a good tradition of these hot fix plugins even predating the repository.
Bundling it may be a solution to getting a “bunch of sites” to make use of the plugin as the average end-user may not be aware of its existence. I would think develoeprs, plugin authors and theme designers may follow the various social media outlets where this is being advertised but the average user tends to be of a “set-it-and-forget-it” mind-set … they are not going to know it’s broke so they are not going to think to fix it.
This is hot stuff for code n00bs like me — as I learn PHP and WordPress, I can now review future hotfixes as isolated in this plugin, rather than having to dig through core code/patch notes to see what was changed. Thanks for publishing1
As cool as the plugin is, I’d rather work to strengthen our own update procedures. That’s going to be a huge focus for 3.2.
Brian, I’m not sure I know what you’re referring to. We decided early this morning that we were not going to go forth with a 3.0.6 release. But Akismet 2.5.3 was being released today anyway, and since it is installed on so many blogs, it is a convenient additional avenue through which a fix can be served. Also, this particular fix isn’t far from the realm of Akismet, seeing it had to do with comments. The Hotfix plugin means we now have a place we can point affected people.
The Akismet update dance is annoying. We get that, but it’s not something we were going to fix for the 3.0 branch. 3.1 will ship with 2.5.3, and we’ll bump to additional 2.5.x releases as appropriate for 3.1.x. Come 3.2, this won’t be an issue, as one 3.2 goal is to stop updating over the wp-content directory.
All’s good Nacin. I was just saying I wouldn’t have minded a 3.0.6 the next day if this was deemed an important issue. This obviously wasn’t. Lots of people get bent out of shape with quick releases. Yeah I don’t like bugs creeping in, but relatively painless upgrades are a better alternative than security holes. And this bug was minor and hard to catch. I’d bet through this bug more people will learn what they can do in comments than previously used the features.. But that’s also why I’m not sure it was important enough to fix through Akismet. That’s all I’m saying.
One thing I would love to see is a consistent way to grab the latest release of any plugin via SVN or the repository. Then I could just request any plugin’s latest.zip or /tag/latest and I wouldn’t have to modify version numbers in scripts.
So now we have the equivalent of several versions of WP 3.0.5 out there: WP 3.0.5; WP 3.0.5 Akismet 2.4.0, WP 3.0.5 Akismet 2.5.3; WP 3.0.5, Akismet 2.4.0 HotFix 0.2; Wp 3.0.5 Akismet 2.5.3 HotFix 0.3, and I’m sure a few other combinations. I’m all for a rapid development cycle. But I think the safer (and saner) release strategy would be to push a 3.0.6 out with the new bug fixed. Or can you have Hotfix change the WordPress version number to 3.0.5.1?
We have an infinite number of versions of 3.0.5 out there, when you factor in all the plugins and the unbounded potential for custom functionality.
Granted. But how many plugins exist only to fix a bug, and then will be obsolete at the next WP revision? I feel that having three different official-ish versions of WP 3.0.5 out there is a problem. Is there a goal of having Hotfix version numbers reflect which version of WP they will work on?
Also, aren’t you WP maintainers going to run into a situation where you have to maintain bugfixes is two places, WP and Hotfix? The Hotfix fix feels klunky.
Also, aren’t you WP maintainers going to run into a situation where you have to maintain bugfixes is two places, WP and Hotfix? The Hotfix fix feels klunky.
In general they are going to be the same fixes.
This bug isn’t serious enough to demand a release straight away but for the people that is does affect the easiest solution is the hotfix.
Simple to Install, No worry about it conflicting when they upgrade WordPress next etc.
Just in case anyone missed it, the fix has also been applied to the 3.0 branch: http://core.trac.wordpress.org/changeset/17421/branches/3.0
So if you’re using SVN to run your 3.0.5 site, svn switching from tags/3.0.5 to branches/3.0 fill also fix the problem.
+1. Branches totally pwn tags, even for stable installs.
The hotfix plugin a weird solution. I like it anyway since it could potentially reduce the number of WordPress updates required. I’m not seeing much point in bundling it into core though, as it isn’t any harder to update the whole of WordPress than it is a plugin. It seems to me that the plugin should be used as a way to point those who are having problems to a simple solution. Then WordPress double point updates could be used solely for security stuff.
This changes nothing about WordPress point-point releases. It’s purely a bonus offering.
The more I think about this the more it bugs me. I get just how minor this bug was but I still think it should have been made 3.0.5.1 or 3.0.6.
#1 most user probably hadn’t updated to 3.0.5 yet. As easy as upgrades have become why make them upgrade, and install a plugin (akismet or hotfix). Why not let them just upgrade and skip a version?
#2 This in theory is the last release of 3.0.x, and many user won’t be jumping on 3.1 immediately… meaning they’ll be using 3.0.5 for some time again meaning that the final release of 3.0.x should be as rock solid as possible.
Maybe someone can explain why releasing 3.0.6 the day after 3.0.5 would have been so difficult, but this seems a case of serving the desires of the development community above the broader user community.
The bug isn not nearly severe enough or common enough to warrant a separate release. That was decided first. The plugin is just a bonus offering for people who are affected by the bug but aren’t comfortable pulling from SVN.
I suspect that the impact of the issue to the WordPress user base affect going this route — what Hotfix is meant to address are inconveniences to a small pool of users vs. an issue affecting *all* WordPress users (ex: security vulnerability). Based on that, a hotfix feels appropriate, especially considering that performing WordPress upgrades can be a time-consuming effort for end users, especially those with multiple sites to administer.
We spun WordPress 3.1 off into a branch. Several of us are at the WordCamp Phoenix core development workshop, and wanted to be able to tackle some minor enhancements or bugs so that we can get “buy in” by the participants and get them their first props.
Subversion switch your test installs to branches/3.1. Except for today at the workshop, we’re not going to be doing any 3.2 stuff. Don’t get distracted! We still need you to test the heck out of 3.1, and are hopeful that we can release soon.
Update: I created a “wcphx” milestone, against which we can close any tickets we do today. That will become the 3.2 milestone after 3.1 is released, so we have the historical record that the tickets were closed against 3.2. I just don’t want to call it 3.2 now or people will start putting tickets in that milestone.
Update 2: We sort of ran out of time before we got to committing stuff. Got a lot of people hooked up with local dev environments (or better local dev environments). and spent a lot of time getting them up to speed on Trac. And of course spreading the gospel of debug bar. Going to just leave the 3.1 branch. We’d have to create it in a few days anyway. So until 3.1 launches, trunk and branches/3.1 should remain identical.
As a reminder:
svn switch http://core.svn.wordpress.org/branches/3.1/
Nice. Does anyone have a webcam going and a UStream channel? Would love to be a fly on the wall…
Not that I know of…
WordPress has always stated that its license was the GNU GPL, and has bundled version 2 of the license, even though no GPL version was specified. The text of version 2 (as well as 1 and 3) says that if no version is specified, the software can be redistributed under the terms of any version of the GPL published by the FSF.
However, WordPress contains libraries which are licensed under the GPL “version 2 or any later version,” which obviously excludes version 1 of the GPL. Here is the reality: the GPL version 1 is effectively irrelevant. It hasn’t been a commonly used license since before Matt Mullenweg was in third grade! Clarifying WordPress as being licensed under the GPL “version 2 or later” resolves these niggling library licensing concerns or ambiguities, and clarifies where WordPress stands.
It was the intention of the WordPress founders and developers to be GPL version 2 or later from the beginning, and we have now made that license properly explicit.
This is a good news! Not because of the version 1 irrelevant angle, but because hopefully plugin and theme developers will mimic this. Currently, most I see are explicitly only GPL v2.
Indeed. And on that topic, it might be good to change (going forward) the license-less assumption of WordPress.org’s plugin directory to be “GPL v2 or later” instead of “GPL v2.”
This is great news indeed. It now clarifies that I can use GPL v3 code in a plugin without any issue.
But you can’t host it in the WordPress plugin repository. And it couldn’t be pulled in to WordPress core. I’d recommend that you license plugins as “GPL” or “GPL version 2 or later” for maximum compatibility.
All my personal code is licensed under WordPress’ license, but the issue is I want to make use of a package that is released specifically under GPLv3, specially Flowplayer. Seems I still can’t use it then (as no point if I can’t host it on WP.org).
There’s no decent Flash video player out there that I can find that is GPLv2. 
“It was the intention of the WordPress founders and developers to be GPL version 2 or later from the beginning, and we have now made that license properly explicit.”
If WordPress itself was written in code as foggy and evasive as that statement, then WordPress would have never shipped because WordPress would have never worked.
There is some evidence of that intention (or at least, ambiguity), which you can see in the public repositories of b2 and WordPress if you’d like. Alternatively, you could just trust us when we say that GPLv1 compatibility is not something we’ve ever cared about!
We want the fogginess to go away: GPLv2+.
Mark, the issue I see here is that what is presented as clarification is probably relicensing. (Depending on how one reads Section 9 of GPLv2.)
Relicensing requires permission from everyone who has ever contributed to the code base. An intepretation of what the true intention of “the WordPress founders and developers” was is not enough.
Switching to a non-GPL license would require a relicensing effort. But merely choosing a subset of GPL versions to distribute WordPress under does not require such an effort, because the terms of the GPL (any version) allow us to distribute WordPress under any version (or range of versions) that we choose. You can’t say that the GPL “any version” grants the freedom for anyone else to distribute WordPress under a version of the GPL of their choosing, but does not grant that freedom to WordPress itself! There is a difference between “any version” and “all versions.”
I’d be happy to discuss this in private, if you’d like further explanation. These sorts of discussions tend to get long-winded, and I don’t want to distract everyone with a big back-and-forth.
Thanks for the additional explanation! It makes better sense to me now.
I’ve been supposing all along that Section 9 of the GPLv2 is open to conflicting interpretations, but when I look into it more carefully, it seems to me I didn’t have good grounds for supposing that.
Cheers!
IANAL, but wasn’t GPL specifically bumped to v2 (among other things) to sort this out?
That was a mistake, that happened without discussion with the leads. It’s better to keep our options open with regards to GPLv3. For example, what if all the good third party libraries go GPLv3 or GPLv3+? We’d have to fork them and maintain them ourselves.
That’s not the issue. The issue is whether you (as in WP) need to ask permission from everyone who has ever contributed to the code base… If so, I’ve yet to receive an email asking to accept (which, I’d answer yes to, of course; but from a technical standpoint, as I read the license, you’d need to do so, with, at your option, some statement along the lines of “if no reply by XYZ we’ll assume you accept”).
(@Dennis — I edited your comment to reflect the correction you sent in your followup comment).
Think of it this way: GPL “any version” means that anybody can distribute WordPress under any version of the GPL. Note my lack of quotes the second time. “any version” → “any version” isn’t required. It is “any version” → any version that we are doing.
It’s strange, I know. But the GPL is sort of a strange copyright “hack.” But just look at all the literature from the FSF encouraging people to upgrade to GPLv3 or GPLv3+. They explicitly say that anyone (including the people running the project) has the option to upgrade from GPLv2+ or GPL “any version,” to a higher subset of GPL licenses. You do not need to ask permission from major contributors, because all three versions of the GPL say that if you don’t specify a version, it means “any version,” which means that anyone in possession of the code can release it under any version (or subset) allowed to them.
What I’d like to make completely clear is that this is allowed by the GPL. Also, we couldn’t, for example, switch to another license like BSD or MIT without asking major copyright contributors for permission.
Ya, I see how it could be interpreted that way as well.
Regardless, I’d like to suggest that the WP foundation check with an IP lawyer and/or the FSF’s legal team if it hasn’t done so already, in order to be 100% sure. Clearing up license-related tickets (in which I’d include the Dolly-related one, which might also need the input of the RIAA) is, I think, urgently needed.
Can you clarify this point?
Shouldn’t this wording be changed also, in light of the licensing clarification?
If WordPress is “GPLv2 (or at your option, any later version)”, then I can’t understand why a GPLv3 plugin would not be accepted into the repository.
Also: nice job on the license clarification. At least to my limited understanding, I think you’ve found the best solution.
Hmm… comment-reply fail. This comment was in response to Mark Jaquith’s response to Alex M.
If we allow GPLv3 or GPLv3+ plugins into the repository, it makes it tricky to bring those into WordPress core at some point.
Well, plug-in code plugin-code and core-code is core-code, right?
@hakre — Yes. But we should probably encourage maximum flexibility, which is granted by a GPLv2+-compatible license.
Okay, so they can’t be rolled into core. I can buy that. (Not sure I totally agree with it, but that’s another conversation for another time.)
But is the inability to roll a particular Plugin into core really a valid reason to prevent it from being available to WordPress end-users, through the repository? There’s a disconnect there that I’m just not understanding.
I’ll echo Chip’s question – why not allow a plugin into the repository, even if it can’t (currently) be rolled into core? Sounds like Alex’s use case above (with flowplayer) is a perfect example of the end-users missing out on a potentially great plugin.
I am asking out of complete ignorance, FYI.
I had no idea it was possible to relicense between GPL versions like that. I assumed once something was under one version, it was permanently stuck under that license until the license holder changed it. Good to hear things are locked in stone like that. Hopefully this will nip all those irritating license arguments that popped up not so long ago in Trac.
I won’t call that actually re-licensing, wordpress.org as any other user has the right to choose the version of the GPL-terms if the version has not been specified. That was written all the time in the license terms that shipped with wordpress. Naturally, the original terms still have to pass with the code otherwise this would violate the code’s GPL.’s terms.
I wrote you an e-mail, so we can talk about “original terms” (like for b2, early WordPress) and the best way to convey that. If the e-mail address on this comment wasn’t the right address to use, provide me with a better one!
I’m curious to know why there’s a long comment related to this that ended up in the trash without being published…
I replied to him privately, at length. I didn’t like the comment’s tone, and didn’t want to kick off a big long public debate over what may ultimately just be a lost-in-translation situation. Figured we could go back and forth in private a bit to get misunderstandings cleared up.
Question: Will a plugin be denied entry into the WordPress plugin repository if it depends on code that is Apache 2.0 licensed? Specifically flot includes excanvas. For reference:
http://lists.automattic.com/pipermail/wp-hackers/2011-March/038334.html
WordPress 3.1 uses jQuery 1.4.4, and jQuery UI 1.8.6. You should check your plugins to see if anything broke. If you were enqueueing jquery-ui-core and using the “widget factory,” or something that depends on the widget factory you will have to update your plugin to enqueue jquery-ui-widget instead. In jQuery UI 1.8.x, the widget factory was separated from jQuery UI core. Please examine wp-includes/script-loader.php to see the entire dependency tree.
Post Format UI and saving is in core. Themes announce their support of various formats like so:
add_theme_support( 'post-formats', array( 'aside', 'gallery' ) );
The UI looks like this, right now:
That UI only shows up if your theme supports it. By default, only Posts support it, but you can add support to other post types like so:
add_post_type_support( $post_type, 'post-formats' );
Twenty Ten has support for the “gallery” and “aside” post formats (it retains its backwards compat support of the special “Asides” and “Gallery” categories).
Post Format is shown on the post listing screen:
That was done very quickly, and I’m soliciting feedback for how that should be conveyed. Head over to the ticket.
Awesome work! Kudos.
This is great. I’ll give it a spin in the next says. Kudos on this feature.
That is great – I’m so exited to make use of them.
Cool!
So cooool
There is a great deal of potential with this concept. Great job!
Is there a method for adding new post formats? It seems the supported post formats are hardcoded into get_post_format_strings().
There’s a filter on the output of that function. Called, oddly enough, “post_format_strings”.
As of r16205 there isn’t. Something gone missing?
Removed in r16198:
Remove post format strings filter. If this is going to be standard, it should be standard.
There was, but I yanked it. The idea here is to standardize. Post Formats are, to start, not much more than a taxonomy convention with a UI wrapper. So if you have “Asides” on one theme, you can transport them to another theme. If people create their own formats, their portability will be zero, or close to zero. While this feature is getting started, at least, I think it makes sense to have requests for new formats go through core. That way we can announce new ones with fanfare, put them on the Codex page, and themers can update their themes to support them. Maybe once we’ve iterated a few times and have covered all the common use cases, we can make it easier to deviate. But to start, a managed economy will result in better standardization.
It’s an unusual way to do things for WordPress — the difference here is that the main sell we’re offering is portability, and flexibility would hamper that goal.
Well, if we’re going to standardize to a set, then might I suggest adding “audio” for podcast usage?
Possibly also “media” or something else for generic multimedia usage. Say for including Flash content that doesn’t fit into Video?
Since it requires the theme to add support, why not just add a bunch? Video, audio, a generic media, image (for a photoblog style), etc.
@Mark – That is beyond awesome. Just wow! As many on wp-hackers know I’ve pushed many times for additions to the core to enable standardization on various fronts and every time I’ve gotten push-back and told that I could write the feature myself. Clearly the idea of creating a standard to promote interoperability among themes and plugins wasn’t a concept that was being appreciated, at least not related to my suggestions. So I’m just REALLY glad to see a feature added to core not because core needs it per se but because it enables themers to add layers of functionality that can be ported between themes. This has the potential to be hugely beneficial to the WordPress ecosystem. Double kudos to you and the team for this one.
@otto and @alex – i agree. besides multimedia (image/ videos/audios), i’d like to add one for events. and maybe in future releases, we could link event format to calendar and create a unique archive page for event format, which displays event posts within a calendar like layout.
Don’t the post formats get their own template in the template hierarchy? Like single-postformat.php, although that could conflict with custom post types.
Wouldn’t it be nice if the default post format was post? get_template_part( ‘the-post-’, get_post_format() );
How does it feel with “Format: Post” as “Default” conveys little information?
I think the issue with that is that they’re all Posts. Blog post, maybe.
Great point. “Blog post” sounds good to me, or pretty much anything other than “default”. I remember a theme named default. She was a good theme.
I’d use “Regular post” to be clearer. Another option is “Normal post” but i think that might convey other posts formats are not “normal”, that’s why Regular post sounds best to me.
@Jose – Wouldn’t “Regular” imply the others are “Irregular?” (See, problem is it’s turtles all the way down.)
Got me there
I think hiding this behind another publish box line is too invisible and will lead to poor visibility of this functionality for themes that support it. Right now that box is bad for a lot of reasons, like all of the identical action links that lead to different things, but I still feel the ideal UI for this is a radio selector. (Which would be useful for other taxonomies too.)
I would rather most themes do not use this default UI, even if it’s improved as I suggest above, because ideally we want them to go a lot further. For example: If something is an Aside, why show the title box? Formats have the opportunity to simplify people’s posting experience, as-is this is just another option.
Maybe we need to auto-hide even more of the metaboxes when they don’t apply to the format as well?
To me that suggests more of a tab UI above the whole post area, rather than something inside the publish box. (Things may jump around.) That might be a lot for 3.1, or maybe not.
If you don’t show a title box you’ll have to re-do the whole posts overview as well. Or your asides will all show up as Auto-Draft (or what it was). Not very user-friendly.
Something Tumblr-like perhaps? http://yfrog.com/gqazxp (though, Tumblr takes you to a separate page when you select a type — which is lame)
@Matt – Would love to see a wireframe/mockup of what you are envisioning…
It would be awesome to be able to select/switch post formats with 1-click (as opposed to 3 right now).
So where do we draw the line between post formats and custom post types? The main difference seems to be that you have a lot more control and power with cpts (including over the ui), and formats are supposed to be theme-agnostic?
It’s just a way to flag the post as a certain style/type so that the theme can style it differently — they’re still normal posts and therefore don’t deserve a CPT.
Asides are posts for example, but they’re short and so are often styled differently.
I like to call post formats intra-loop styling for your blog. Post types are non-post objects. The use cases only overlap when you’re using one of them horribly wrong.
I did a couple of mockups of what i think would be a nice way to show them. It would be two-click, easy to spot but not distracting (at least to me), and since it’s something i’d probably edit before writing the post, i think the position is not bad at all. In any case i think a little mockup can help others get more ideas too. I did put some quick and dirty icons copy pasting from the admin panel.
The position in the title box may not be the best one for lower resolutions but somewhere near the area would feel right to me.
http://s.moskis.net/formatpostmockup1.png
http://s.moskis.net/formatpostmockup2.png
Probably not the best position for it given that some formats don’t even have titles, but this is really cool. Also a fan of the icon attempts.
This is too late for 3.1 though, we won’t be thinking about this until 3.2 at the earliest and we’re happy with the UI we have now. But we’ll revisit this at some point and I’ll keep this mockup in mind for sure.
Also, if you’re a designer, you might be interested in participating in our UI group: http://make.wordpress.org/ui/. See the sidebar on that blog for their meeting times.
What about a post formats drop-down in edit.php so users can easily see all posts of a particular format… http://petem.in/n
I really like this idea, but think that it should extend to all taxonomies which the users could define via screen options.
Mark
While you’re looking for post types / formats – please add “events” to the list.
Events have their own format which could be supported by custom fields, taxonomies etc – e.g. when where what who and so on. In many ways, this is no different to media and video/audio needing their own format. Events have (at least) two dates associated – date of posting, and date of event – these are rarely the same.
Gaz
I brought up events too, but then they pointed out that Events are really better handled by Custom Post Types which you can already do in v3.0. Post Formats are really for different use-cases. FWIW.
@Mark, this is great news, stuff that I had to earlier do with post tags and categories is packed into post formats. Although I’m still quite concerned about, say styling out a gallery post with text before and after the thumbnails. I used to do this through shortcodes before, guess I’ll now have to combine the two. Anyways, thanks for sharing this, waiting for 3.1
Cheers.
I really like the idea giving post a certain format. That may save some time for those who insert lots of pictures from time to time.
Can’t wait to see the results. Happy coding!
I have wanted this for so long.
Are there eventual plans to expose fields specific to certain types? For example, a quote should probably have an “Author” and “Source” fields. Or is this better left to plugins?
If the plan is to define specific post formats, Tumblr-style, then that would be logical.
A question to ponder; given that Post Formats are “intra-loop styling”, it would seem that some of them could be Post Type-specific? For example, I could see an Event as having different formats such as “Single Presentation”, Single Day”, “Multi-Day”, and probably more. Thoughts?
It’s a way to describe their functionality, but that’s not the reasoning behind them, which is standardization and portability between themes.
Good point. I applaud the effort to enable a standard for portability; that’s probably more important that too-much flexibility in this case. People can always come up with a custom field value as a switch for their own custom themes.
Love the feature already. It always annoyed me to format posts by selecting a category. Can’t wait to select , or formats in the WordPress for iOS app.
Suggest topics for the July 15, 2010 dev chat.
PHP 4 EOL discussion.
What do the current phone-home stats show as the version use?
For WordPress 2.7 and higher, 7.56% are using PHP 4.
For WordPress 2.7 and higher, 3.60% are using PHP 5.0.x or 5.1.x.
Combined, that is 11.16% of WordPress installs using a PHP version lower than 5.2.
However, we considered that people running an older branch of WordPress might be disproportionately using older versions of PHP, because of self-managed servers or a lazy hosting provider. We’re waiting on that data. Little elves are running in a hamster wheel.
It is expected that if we announce an EOL for PHP versions less than 5.2, and give enough warning, that some hosts will upgrade (or change their default). So those numbers will go down. Also consider that both Drupal and Joomla are going to require PHP 5.2 sometime this year. If WordPress was on board, that would be a heck of a motivating factor for the laggards.
Big and excellent move. It might be the right time to launch such a discussion, with the current cycle focused on 3.org, minds can still be made before the team moves into actual coding in September. If we count an approximate 3 months of dev time for 3.1 (provided that is the version that would receive such treatment), that leaves half a year of Internet-evolution before the move is applied.
Now of course, it might be decided to go slow and only place some more PHP5 warnings into the 3.1 code, and make the complete move at a later time (PHP5 -> 3.5? argl).
Now, one thing that could be useful, along with phone-home stats, is to dive into a list of hosts and see how well they are prepared for such a move — and maybe start a mailing campaign to get ready.
A joint announcement with Drupal and Joomla would certainly help, too.
Drupal made their plans known a few years ago that version 7 would be PHP 5.2. I’m not sure when Joomla announced their plans, but 1.6 is currently in late beta and it also requires PHP 5.2.
My opinion (at least before we queried these stats yesterday) is in 3.2 we should bump the limit, remove compat code, etc. What’s killing us is testing coverage, not the lack of PHP5 features. If we do any “You’re running PHP 4″ warnings that’d be for 3.1. But we’ll discuss at the dev meeting. Most importantly, reaching a decision and announcing a firm date now provides hosts a timeline.
And we can wish and hope all we want, but a three month dev cycle just isn’t going to happen
What’s killing us is testing coverage, not the lack of PHP5 features.
I suspect the real harm is an invisible brain drain. Why would PHP programmers be eager to contribute code to a project that requires them to use a dead language, in particular a dead syntax?
Excluded are those who love to program, are new to WordPress, and know what they’re doing. It would be hard to prove we’ve lost too many of those kinds of people until it’s too late.
Somehow, I know you’d burn me on the “3 months dev cycle” thing
filosofo: Excellent points.
If we decide on 3.2, I would recommend that we incorporate that knowledge the update-core.php. It could display an error message at the top & prevent upgrades to 3.2 or higher.
While we are in there core_upgrade_preamble() could use another action call. It makes sense to have one up right where the announcements are echoed out.
WordPress 3.0 already includes a PHP/MySQL version check before upgrades, I’m pretty certain that displays a warning and prevents updates if they dont match..
You, Sir, are correct. It’s built into list_core_update(). Good catch.
I’m down for 3.2, or more generally whatever release is in Q1 of 2011.
Should we bump to 5.3 as recommended?
I’m down for 3.2, or more generally whatever release is in Q1 of 2011.
That’d be 3.1 then, which isn’t bad, and we can simply tell hosting companies Q1. I said 3.2 originally but I didn’t realize the stats were in our favor to do this sooner. This also prevents us from needing to do any major refactoring or feature development in 3.1 but still need to use PHP 4 syntax and constructs (lame duck). 3.org also gives us an additional cushion that allows us to aim for 3.1 — hosting companies will have a solid 6-7 months to make adjustments.
Should we bump to 5.3 as recommended?
More people are on 4.4 than 5.3, so the stats just don’t support that, unfortunately. The good thing is, the stats do solidly support a jump to 5.2.
For everyone’s reference, here’s the stats for all WordPress 2.7+ installs:
4.3 – 1.3%
4.4 – 6.3%
5.0 – 0.1%
5.1 – 3.5%
5.2 – 85.4%
5.3 – 3.4%
I wouldn’t be surprised if a large portion of the 5.3 installs are local development installs where people have control and tend to run the latest version of things.
5.2 looks like the key winner here.
+1 to 5.2
5.3 deprecates a lot of stuff. We’re good with WordPress, but a lot of other scripts likely won’t be and I bet a lot of hosts are holding off as a result.
What are the stats for 2.9+? I think we should only consider the people that are likely going to upgrade to the next version of WordPress. What would you do if you knew that 6% of installs would never upgrade from WordPress 2.7 and would never upgrade PHP from version 4.4… until their servers killed over. Is there any correlation between running an outdated version of PHP and an older version of WordPress?
@Dan: I think it’s safe to assume that there is enough of a correlation to bring down the percentages a bit for older versions of PHP, though probably not much. Mark said he was waiting on that data. (“Little elves are running in a hamster wheel.”) We’ll make sure to have it for Thursday, though I think the 2.7+ data is plenty persuasive on its own.
Does making the recommended php version 5.3 help move us toward to 6.0 compatibility?
The Backwards Incompatible Changes list doesn’t look too bad over 5.2: http://us2.php.net/manual/en/migration53.incompatible.php
And the E_DEPRECATED error level should help mitigate any issues that do arise: http://php.net/manual/en/migration53.deprecated.php
The required version would be 5.2 right?
Oh… my… god. Finally, we have reached the mythical PHP4 < 10%.
PHP 5.2 is the way to go.
PHP6.0 should not be considered at the moment as news suggests that the PHP developers might go in a new direction with regards to what PHP6.0 is. As of right now, I’d suggest you think of PHP5.3 as PHP6.0 until new details comes out.
5.3 has had some problems (5.3.1 had some serious issues that breaks things) and it really isn’t there yet on enough hosts for it to be a viable target. I say go for 5.2 compatibility, or just 5.0+ compatibility.
From the PHP perspective:
All of that said, if you require 5.2 as a minimum, you should make sure it’s 5.3 compatible and doesn’t throw all kinds of E_Deprecated warnings. Some plugins are likely to misbehave if you leave any.
@Keith: All my WordPress sites run PHP 5.3. It was a bit rough at first with all of the warnings, but they were resolved long ago.
What are the numbers on PHP 5.2 and 5.3?
The stats for WP 2.9+ weren’t significantly different. 85.2% on 5.2, and 3.2% on 5.3. Regardless, I still feel strongly about targeting PHP 5.2 for our first 2011 release.
Did someone misread the haiku statement?
From the more general PHP perspective.. going 5.3 only is *very* premature. Some of the major frameworks – name the Zend Framework, Symfony, and Lithium (build by some of the CakePHP team) – are or are going 5.3 by Q1 2011, but they target and reach a completely different segment than the average WordPress installation. My 0.02.
Suggested topic: Initial 3.org contact reports by the 6 team leads:
API Reference. Andrew Nacin
Handbooks: Jane Wells
bbPress: John James Jacoby
PI: Support: Mark Jaquith
PI: Commmunity: Peter Westwood
PI: Core: Ryan Boren
I don’t think we can require PHP 5.3 until it’s widely available in the popular Linux package repositories. Debian current stable, for example, has the PHP 5.2.x package.
I definitely agree, but I don’t think that is what was being discussed.
Matt’s wording “Should we bump to 5.3 as recommended?” could be read either way but I think he is referring to this section of the codex:
http://codex.wordpress.org/Hosting_WordPress#Recommended_setup
We already recommend 5.2 today. This is a just a soft push forward. The required and recommended versions are not often identical.
You’re right. Sleep deprivation had me reading “recommended” as “required.”
Either that or I’m just so giddy about being able to kick PHP 4 into the rubbish heap.
Yeah, there are new functions like json_decode that sound really neat, but I’m not sure all this new fangled “jason” stuff 5.0 gives us will ever catch on. SERIALIZATION FTW!
Yes, it’s recommended. Since we’re going to make a big push around hosts, it would be worth getting them on something we’re comfortable with for 3-4 years down the road.
I’ve always wondered about the stats we see from hosted users. Are there really a lot of hosts that *only* offer PHP4? Or are there a lot of hosts that have both available, but default to PHP4, or users who came on board with PHP4 and don’t know/care that PHP5 is an available upgrade?
I suspect the latter, but have no evidence.
Suggested topic: bot@im.wordpress.org What do you want to subscribe to?
Set up team to evaluate shared-hosting providers for WP.org recommendations.
Trac ticket of the proposal: http://core.trac.wordpress.org/ticket/14087
This is also tangentially connected to the PHP4 EOL discussion.
Agenda for the July 1st, 2010 dev chat:
Summary:
Just a quickie note: I just added a drop down menu to wp.org on the Extend toolbar item, as requested by Matt. Should show a dropdown for faster access to the plugins and themes areas in Extend.
Thomas, 
Johan, and 60 others are discussing. 
Jon Brown, and 11 others are discussing. 
Travis, and 8 others are discussing. 
Pete Mall 7:19 pm on February 1, 2012 Permalink |
I’m working on the patch for the add-user-to-blog screen in the Network Admin. Patch should be up on the ticket in the morning.