WordPress 3.3 Proposed Scope
This document will not be finalized until the conclusion of the IRC meeting today. Per last week’s IRC meeting, the core team has reviewed the potential features/projects for 3.3. Only features that are assigned to someone by the end of today’s will be included in the official scope. Note: Assigning everything to Nacin does not count.
User Feature: Media Uploader (azaozz)
- Definitely v1: Integrate Plupload into dashboard. (GSoC project)
- Probably v2: Improve our image manipulation and gallery management.
- Nice to have: Kill all thickbox usage, move everything inline.
User Feature/UI: New User Experience (jane, koop)
♫ Feels Like the First Time ♫
- 1st time install welcome screen – intro text and checklist of “steps” to get going.
- 1st time post-update welcome screen a la Mozilla.
- 1st time exposure popup for new features a la facebook, twitter, etc.
Note: Matt says WordPress.com is working on similar features there. Will connect with them and see if/where there is overlap and work with them when possible to free up some of Koop’s time.
UI: Responsive Admin (saracannon with azaozz, koop)
Make the admin dynamically display nicely on devices of various screen sizes (including wider screens) and human interface mechanisms, such as touch. Plotting and specifics to happen on UI blog and in weekly UI meetings.
- Performance: CSS files merge (especially RTL) / remove duplicate styles.
UI: Improve Admin Bar (koop, jane)
Continue the admin UI work started in 3.2 and work toward combining admin bar (in dashboard) with admin header to reduce duplication and save vertical space.
Internal: Performance Improvements (markjaquith, jon)
- Permalinks
- #17177, #15915, #16687, others
- The permalink structure is highly desirable, but it doesn’t scale beyond 50 pages or so.
- /%postname%/ permalinks without performance penalty
- /static-slug/%postname%/ permalinks without performance penalty
- Consider retiring verbose rewrite rules all together in favor of queries.
- Finally fix the issues relating to special characters in permalinks using an upgrade routine (#16036 and others)
- Nav Menus
API: Meta Improvements (ryan, koop, others)
- register_meta, new caps, *_metadata_by_mid() (nearly done)
- Nice to have: WP_Meta_Box (proof of concept posted)
API: Settings API Improvements (ryan, petemall, scribu, markjaquith)
- Convert table markup to CSS
- Nice to have:
- Make settings fields/forms/errors construction less painful
- Use the settings API in the Network Admin
- Kill options.php as a POST handler
Internal: Language Packs (nacin with SergeyBiryukov)
Merge in GSoC project. Will require quite a bit of development across GlotPress, api.wordpress.org, and core. (As in, needs additional owners.) In the next week we should come up with a plan of action for how it should all work, as there are currently many questions. (#18200)
Updates/Upgrades (nacin, dion, otto)
- Internal:Â Partial build updates, version 2 – md5 verifications of files – nacin, dion
- Feature: Ability to install child themes (in the theme directory) via the theme installer – otto
- Enhancement: Core changelogs via the update check, to entice updates
Secondary Items
Deprecate IE7 in the Admin for 3.4
Everyone hates IE7. It’s insecure. Let’s make it go away. Also, dropping IE6 didn’t give us much beyond goodwill, because most of the hacks we needed for IE6, we also need for IE7. So we could actually clean up our CSS a bit if we dropped IE7.
Not happening for 3.3, will target 3.4. Once we hit freeze or RC someone could start working on this to have it ready to go in the minute we open 3.4, to provide the maximum testing time.
API: Editor API improvement (azaozz)
Update/refactor Quicktags (mostly done) and combine all supporting functions.
User Feature: Press This
Plugin now, target 3.4 for core.
- Make Press This better in a nebulous and undefined way.
- Browser extensions? (mitcho?)Â See also
Mixed Bag
These are things we really want, but no one is assigned to them. This is a great opportunity to earn some core cred by taking a greater role and spearheading development of a feature.
- UX: Dismissible admin notices – sorich87
- UX: better management of workflow in editor (joe is currently editing this post any changes etc) – markjaquith
- Design: HTML E-Mails – Leverage Wojtek’s GSoC work – westi
- Death: remove (finally) compat functions from the widgets API and cleanup converting of old settings (will require copious unit tests first) – azaozz
- UX: Don’t lose widgets on theme switch (#17979) – AaronCampbell
Christopher Wallace 4:19 pm on July 27, 2011 Permalink
I’m wondering how moving the media upload stuff inline will affect third-parties that tap in to the image uploader.
Gerry Ilagan 10:33 am on July 28, 2011 Permalink
I think it would be great if a new set of media upload functions are created so as not to disrupt current plugins and slowly phase out the old methods.
It would also be great if the new media upload functions are “modularized” with exposed API’s so that developers can for example use media upload to select an image and assign it to a meta field variable
Daniel Chatfield 8:49 am on September 27, 2011 Permalink
I’m also worried about how that will affect current plugins. The thickbox definately needs replacing though (“insert into post “confuses users when there is no post to insert into and changing the text via javascript is very hacky).
Andrew Nacin 4:35 pm on July 27, 2011 Permalink
If you want to help with anything, or wish to claim something out of the mixed bag, please post a comment.
Chris Wallace 4:38 pm on July 27, 2011 Permalink
I’d be happy to take on the “UX: Dismissible admin notices” item from the mixed bag.
Andrew Ozz 4:41 pm on July 27, 2011 Permalink
@sabreuse and @DH-Shredder can help with the CSS files merge and cleanup.
Sergey Biryukov 4:59 pm on July 27, 2011 Permalink
I also volunteered for that, would be more than happy to help with RTL.
alex 4:44 pm on July 27, 2011 Permalink
I can’t wait to see the 3.3 version.
I like very much the theme editor from Shopify. It’s ajaxified and it’s very easy to use. It will be great if the WP theme editor will be ajaxified, changing the files in the editor without refreshing the page.
I can help with that
Daniel Chatfield 8:51 am on September 27, 2011 Permalink
I’m willing to help as well.
DH-Shredder 4:45 pm on July 27, 2011 Permalink
Also certainly happy to assist with the Language Pack merge, if you need further hands.
Dougal 4:48 pm on July 27, 2011 Permalink
There was mention in the chat about improvements to XML-RPC and Atompub. Also related, I think, was a GSoC project for an improved Android client app? I was going to get with @josephscott about some of the xmlrpc stuff.
Joseph Scott 4:52 pm on July 27, 2011 Permalink
Lets go through the list of XML-RPC and AtomPub tickets, see which ones look viable for 3.3.
Prasath Nadarajah 4:09 am on July 29, 2011 Permalink
I’d be happy to help. There are a lot of security leaks to be fixed in XMLRPC. I submitted a few patches. We could improve security in 3.3
Prasath Nadarajah 5:41 am on August 16, 2011 Permalink
I have added tickets in the trac for new functions and updated it with patches.
please have a look.
Aubrey 5:00 pm on July 27, 2011 Permalink
Having ran many websites for educational use, I would suggest continued support for IE7. Many Universities, especially here, have faculty/staff that use older browsers (even IE6). Just a thought and a perspective.
Rami 9:44 am on July 28, 2011 Permalink
WordPress droped support for ie6 (and soon in ie7) only in the back-and, not in front-end.
Daniel Chatfield 8:52 am on September 27, 2011 Permalink
I wouldn’t support the drop of IE7 if it wasn’t for the fact that chrome frame can be installed without admin rights. With chrome frame there is no need to support IE7 in the backend.
Mike Schinkel 5:16 pm on July 27, 2011 Permalink
“Consider retiring verbose rewrite rules all together in favor of queries.”
Would love to hear an elaboration on what is planned for this?
I have a working low-level plugin that sits in front of parse_request that parses a tree of URL routing instructions to determine what values to set in $wp->query_vars; otherwise everything else is handled by WordPress core. The plugin is coded to be reasonably peformant, especially compared to the current rewrite rules system, and can easily be optimized via hooks to improve performance down any pattern or path branch, and its code footprint is currently much smaller than the code that handles rewrites. It provides almost full flexibility for URL routing and follows other WordPress conventions as closely as possible (i.e. you use the same format for URLs as you do in the permalinks page, i.e.:
register_url_path( ‘%category_name%/%name%’ );
It also provides tree-oriented metadata that would make automatically generated breadcrumbs and sitemaps easy to implement in core.
I have been planning to release as part of a planned package of plugins for improvement WordPress’ use as a CMS but would be happy to provide it as a base for inclusion in WordPress core if the team is interested.
scribu 8:52 pm on July 27, 2011 Permalink
It would be awesome if you could upload it to one of the rewrite tickets.
Mike Schinkel 10:32 pm on July 27, 2011 Permalink
Cool. I’ll add some inline docs and upload ASAP.
Mike Schinkel 7:40 am on July 28, 2011 Permalink
Done: http://core.trac.wordpress.org/ticket/18276
William Lindley 6:06 pm on August 15, 2011 Permalink
Is there any hope for non-unique yet hierarchically unique slugs, so I can have /railway/stations/ma/springfield and /railway/stations/oh/springfield and /railway/stations/il/springfield …? Currently these have to be …/ma/springfield-ma, /oh/springfield-oh, and so on, despite the full path being unique. We have waited a long time for this!
Mike Schinkel 5:35 am on August 18, 2011 Permalink
Hi @William Lindley:
Looks like core won’t be addressing that issue anytime soon (as per my discussions with Andy Skelton and Nacin at WordCamp SF) but you can address those types of URLs using the approach in the attachment to the trac ticket #18276. If you need help with it, contact me directly.
Wojtek Szkutnik 5:27 pm on July 27, 2011 Permalink
I will be developing the Enhanced Emails project after GSoC as well, I don’t know if it’s 3.3 or 3.4 material but I will definitely be working on it until it makes it to the core.
Amy 5:28 pm on July 27, 2011 Permalink
Also interested in helping out with Settings API work – @sabreuse
Trevor Sullivan 5:39 pm on July 27, 2011 Permalink
Better Admin UI performance would be fabulous … one major reason I use Windows Live Writer to compile articles.
Brian Layman 6:05 pm on July 27, 2011 Permalink
There are a couple core related defect fix tickets I really hope to see in 3.3 to eliminate some core hacks that I’ve had allow older sites to run again under 3.1+. Would be cool if this could be brought up in the IRC chat.
I think that putting http://core.trac.wordpress.org/ticket/17998 in is going to be extremely helpful for large sites. I would really like to see that put in and it is a single line change that eliminates hours/days from the normal upgrade process on large networks.
And since we are doing testing on permalinks, I think it would be a great time to look at http://core.trac.wordpress.org/ticket/18079 . That fixes WordPress so that it once again allows path based blog networks which broke sometime in the 3.0 release and is preventing some people from upgrading. If this can go in, I can do the search for other $base uses as Nacin recommends and update the patch.
iamfriendly 6:16 pm on July 27, 2011 Permalink
With regards to the ‘first time exposure popup’ has anyone seen this : http://tympanus.net/codrops/2010/12/21/website-tour/ — looks pretty damn cool and could be useful?
I’d be interested in helping out with this…?
Wycks 8:54 pm on August 13, 2011 Permalink
I hope this gets looked at, this plugins UI for image handling is very good.
Eric Marden 8:22 pm on July 27, 2011 Permalink
Rejoice!
arena 11:50 pm on July 27, 2011 Permalink
When using the_editor in a plugin, really difficult to remove the ‘fullscreen’ option !
Alex Mills 12:24 am on July 28, 2011 Permalink
#17994
Subh 5:27 am on July 28, 2011 Permalink
The point ” Deprecate IE7 in the Admin for 3.4 ” should be considered carefully as Most of the Govt. organisations, Schools, some banks etc. always use IE and IE7 is the default for them. Yes, if we think from the developers’ perspective, then everybody hates IE7, but from the users’ perspective its needed…
avcascade 7:03 pm on July 31, 2011 Permalink
Define “most of govt organizations, schools, some banks”
IE 7 was released in 2006. It’s half a decade old now. That makes it obsolete. Governments and large corporations running Windows XP or Server 2003 can upgrade to IE 8. And a great many have.
An organization that managed to get from IE 6 to IE 7 should be able to get to IE 8.
In the last few months, IE 7 has seen a significant drop in use. By the time WordPress 3.3 is out, usage will have declined further.
http://gs.statcounter.com/#browser_version-ww-monthly-201102-201107
Deprecating backend support for IE 7 seems like a good move.
iamfriendly 10:34 pm on August 17, 2011 Permalink
I can’t disagree any more, to be honest. Saying organisations “can upgrade” doesn’t mean they WILL upgrade.
The largest company in Europe – the NHS – by default, uses IE6. They “think” they are unable to move away from it because of 2 reasons: 1) outdated tech support people who are too lazy/incapable/busy to upgrade millions (and I do mean millions) of systems from IE6 and 2) There is an inherent cost involved in upgrading all of these machines, like it or not, they are locked down, so they need an administrator to update them, which takes time and as we all know, time = money.
Completely dropping IE6 support from the admin, for me, was an error. I’m busy trying to write a plugin which makes the dashboard of 3.2 actually usable in IE6. I’m not having much luck.
Dropping support for IE7 is *probably* a bad move, also. Many of the military machines here in the UK use IE7 as do many council computers (local government).
Don’t just completely drop support for IE 6/7. At least create some sort of basic – I don’t care how ugly – and functional back end. I’m all for looking forward and I’d rather IE6/7/8 never existed, but they do and some people are stuck with them.
In this instance progressive enhancement is a *much* better idiom than graceful degradation. Sadly, with 3.2, there was no grace or progression.
Subh 5:30 am on August 18, 2011 Permalink
You can not force a client to upgrade their Browser… also they don’t know how to upgrade… Their are some employee in organizations who don’t even know about all these things… they just use the computer given by the authority which runs Windows XP and the default browser in it. If the website doesn’t open they start saying this application is faulty, they don’t understand that this is developed in WordPress which is not supporting your browser version and all.
So it will be a bad move to completely drop support for IE7.
Daniel Chatfield 8:55 am on September 27, 2011 Permalink
Chrome frame can be installed without admin rights – most people who will be administering a website will know about upgrading browsers. I was a little surprised at how IE6 support was dropped and perhaps a redirect to page informing people about the choices of browser and why we have dropped support would be better than the mess that currently appears.
Wayne 8:47 am on July 28, 2011 Permalink
One thing i’d really like, is to allow more than 2 columns on custom post type editor screens.
2 columns makes sense for traditional posts, but sometimes i have custom post types that are just a bunch of meta boxes and it looks bizarre squashed into 2 columns
Tina Thompson 1:21 pm on July 28, 2011 Permalink
THANK HEAVENS that the media handler is FINALLY being addressed. Without a doubt it is my number one issue on the backend of any site that I manage, as it is slow, limited and just a general PITA.
Jan Fabry 6:06 pm on July 28, 2011 Permalink
“Improve our image manipulation and gallery management” – is there a Trac ticket or another place where I can follow this topic? I’m very interested in it (and maybe even able to help).
scribu 10:48 am on August 1, 2011 Permalink
#18206 for a start.
Rafael 9:14 pm on July 28, 2011 Permalink
Have you considered something like this plugin for the Section User Feature: Media Uploader -> Probably v2: Improve our image manipulation and gallery management.
http://www.mihaivalentin.com/image-pro-wordpress-image-management/
BjornW 12:32 pm on July 29, 2011 Permalink
As others already have mentioned ditching IE7 sounds nice, except many big(ger) organizations, corporations and goverments still use IE7 and will not update soon. I’d like to suggest to support IE7 for now.
redwall_hp 3:54 am on July 30, 2011 Permalink
I have a UI suggestion: how about dropping the grey background on the Dashboard widgets and meta boxes? It looks kind of ugly. I think making it white, like in previous versions, would look a lot better. (I’ve already tested it with Firebug, and it looks a lot more pleasant to me.)
Chelsea Otakan 8:50 pm on July 30, 2011 Permalink
Could we do some settings UI improvement in addition to the API stuff? If that fits in here, I’d love to work on it :]
Andrew Ryno 12:21 am on July 31, 2011 Permalink
I’d love to help on it as well. I think the UI part of the settings will wait until after they work on the API a bit. Since all the markup will be generated by the APi.
Andrew Ryno 12:23 am on July 31, 2011 Permalink
I would love to help get rid of Thickbox. I don’t really care if it takes up all my time and stops me from working on other tickets. It needs to be done and if azaozz is going to work on other media stuff, this would be the best time.
Andrés Sanhueza 5:50 pm on July 31, 2011 Permalink
Regarding permalinks, when one adds a custom slug to the default posts, they get added for everything else (categories, tags, attatchment, date archives, etc.). This will be fixed in some way?
Sylwia 6:51 pm on July 31, 2011 Permalink
Great news about the picture gallery!
Chris 2:42 pm on August 8, 2011 Permalink
Seriously, do you hate everyone that works at big companies?
I love WordPress, but the way that IE6 has been totally, utterly blocked from functioning means I can’t access it on half the NHS computers.
Luckily, the other half of them use IE7, which is fine… unless you block that too.
Make it look horrible, make it work slowly, have a ten foot banner that plays MIDI tunes: just don’t make it totally non functional!
Jane Wells 2:48 pm on August 8, 2011 Permalink
You should be able to use Chrome Frame with IE6 to get access. Does the NHS know you’re using their computers to update your WordPress site?
iamfriendly 2:55 pm on August 8, 2011 Permalink
The point Chris is making, and it’s a valid one, is that several of the websites of NHS organisations *run* on WordPress. I’ve set several of them up! They are stuck with IE6, not through their own choices, but because of the expense of upgrading.
Using Chrome Frame means you need to install it. Installing it normally needs administrator rights. Now, I know that Google has updated Chrome frame so that you don’t need admin rights to install it now, but most people (the vast majority) do not realise they can do this. Hell, not even NHS sysadmins know this. They also do not realise that installing Chrome Frame wont affect other sites.
I’ve begun an ‘NHS education’ for all of our clients, but the pickup is massively slow – they see the words update/install/upgrade and all they really is is ‘this is going to cost me money’.
The NHS is the largest organisation in Europe. Hampering them using WordPress is a grave error in my opinion. Even worse, many sites that already use WordPress can’t be upgraded to 3.2 and so, in the future are going to become possible targets for attack.
I’m all for moving forward and increasing browser awareness. I’m all for modern web standards. I’m all for ‘let’s kill IE6 asap’. I’m also all for making sure that my sites are accessible and usable to my clients and ensuring that they are secure. Throw us a bone?
Jane Wells 2:59 pm on August 8, 2011 Permalink
@iamfriendly: If someone wrote a page in the Codex that explains about Chrome Frame not needing admin rights, then wrote a patch to amend the IE6 warning box in the admin to include a link to that page, Id support it.
Chris 3:02 pm on August 8, 2011 Permalink
Oddly enough they don’t seem to mind me editing my medical education blog when working as a medical educator
At the WordPress user group I’m in, we honestly felt that the attitude of WP to IE6 was cocky. Fair enough, don’t “test” it thoroughly, but make it, at minimum, just about functional.
I have tried and tried to get Chrome Frame running at work, but the admins still managed to block it.
“Throw us a bone” says it all. I don’t want you to promote IE6, but you are choosing to show the finger to a huge potential market, to what gain? I refuse to believe WP 3.2 couldn’t run just as slickly with a conditional IE6 stylesheet changing about 3 settings.
Chris 3:03 pm on August 8, 2011 Permalink
@Jane – the warning box gets turned off on every install I send out – if you’ve got novice users, the last thing you want them to see is a massive panic box hehe.
iamfriendly 3:03 pm on August 8, 2011 Permalink
@Jane I know a hint when I see one. That’s actually a tremendous idea. I’ll go about compiling the copy for that page on the codex.
@Chris do you want to help with that? (Or anyone else for that matter). Once the page is up, the patch to the IE6 warning box is simple.
iamfriendly 4:55 pm on August 15, 2011 Permalink
http://codex.wordpress.org/User:Iamfriendly/Information_About_Google_Chrome_Frame_for_Internet_Explorer_Users
OK, so have made some amends – would be interested to hear if that’s the sort of thing that would be useful. @Chris & @Jane would love to hear what you think?
iamfriendly 4:21 pm on August 8, 2011 Permalink
Very early draft, but… feedback?
http://codex.wordpress.org/User:Iamfriendly/Information_About_Google_Chrome_Frame_for_Internet_Explorer_Users
iamfriendly 4:22 pm on August 8, 2011 Permalink
Bah, sorry this should be a reply to the above thread about Google Chrome Frame. Anyone able to move it? (Also, looks like the title is too long, shall I just rename to “Google Chrome Frame” ?)
arena 8:41 am on August 9, 2011 Permalink
Nothing about Twenty twelve theme (which might be the last wp theme hé hé !) ?
Wojtek Szkutnik 8:44 am on August 9, 2011 Permalink
I would go for it just for the sake of having such a terrific default theme name
Jeremy 4:13 pm on August 26, 2011 Permalink
Hello all,
The Blog Team at The New York Times has two editor-specific features that we would like to add to WP 3.3.
We recently developed a lockout feature for WordPress. This feature notifies you if you attempt to edit a post, and another member of your team is currently in the post. You have the options to read only, preview, and if you are an Admin, steal the lock. If you are editing a post, and you walk away from your computer or you have moved to another tab, you are given a brief time period to keep the lock, otherwise it saves your work and puts you in read only mode. If a post is currently being edited, a small lock icon appeas on the All Posts screen. Hovering over the icon reveals the details of who is editing the post.
We also built a very useful notes area in a WordPress post. This allows editors to leave notes to each other about the specifics of a given post. Our editors use it to indicate if a post needs another editing pass, or if a post is waiting on a photo from the photo desk. Or sometimes information from the reporter on what the progress of a story is. If a post has a note attached, a small icon appeas on the All Posts screen. Hovering over the icon reveals the note. This helps an editor to scan multiple posts at once and check on progress and manage the day.
We are also very interested in contributing our Live Blogging solution to WordPress.
All of these were developed for our newsroom, and have proven to be really useful for us.
Andrew Ozz 7:39 pm on August 29, 2011 Permalink
This sounds great. Post lock improvements are scheduled for 3.3, there’s a ticket too: #18515. Perhaps we can implement your solution there.
The post notes area sounds very interesting too. Perhaps it won’t benefit the majority of sites (most seem to have 1-2 users only) but seems it will be a very welcomed addition for all multi-user sites.
Jeremy 9:40 pm on August 29, 2011 Permalink
It might make sense for a feature like NOTES to turn on when there are over regular X users on a site.
Eric 12:33 am on September 2, 2011 Permalink
/%postname%/ permalinks without performance penalty
does that mean you’ll fix all performance penalty for any permalinks that start with dynamic text like /%category%/ with base . ? or are you guys just fixing domain.com/%postname%/
Andrew Nacin 3:09 am on November 16, 2011 Permalink
All of them were fixed.