WordPress 3.6 Cycle
I’m going to be leading the WordPress 3.6 cycle. I’d personally like the focus of the release to be about content editing (revisions, autosave, workflow, editing modes, etc), but of couse that won’t be locked down until we have our IRC planning meeting in early January.
What I need in the meantime is to pick a backup lead. Someone who will help me with the planning, execution, and delivery of the release, as well as be able to step in if for some reason I am unable to finish. If you think you’d be a good person for that job:
Marko Heijnen 9:09 pm on December 19, 2012 Permalink
I’m curious if there would also be a focus on bringing the open tickets down. Even this release there where more tickets opened then closed.
Andrew Nacin 9:11 pm on December 19, 2012 Permalink
Yes. This is going to be a separate initiative from the release itself. More in a few weeks.
Nashwan Doaqan 8:04 pm on December 20, 2012 Permalink
Good , Sure thing we should add more features to WordPress , I have some ideas and I will open some tickets soon , anyway I hope WordPress 3.6 be another success version
Tom Lynch 10:56 pm on December 20, 2012 Permalink
@markjaquith is there not room to look at the Settings API which I and others have highlighted several times and keeps being passed over?
Erlend Sogge Heggen 2:58 am on December 21, 2012 Permalink
Would this update to “content editing” include a re-evaluation of TinyMCE and its alternatives? (such as wysihtml5, Aloha Editor and CKEditor)
Some relevant discussions:
http://wpmu.org/why-you-hate-the-wordpress-text-editor/
http://wpmu.org/what-i-would-do-to-improve-wordpress/
http://wordpress.org/extend/ideas/topic/improved-visual-editor
Mark Jaquith 8:23 am on December 21, 2012 Permalink
I’d like to make it easier to support other editors, for sure. As for looking at alternatives — we do that constantly. But we’re also trying to work more closely with the TinyMCE team. A switch would have high costs, and it would have to be worth it. It behooves us to try as hard as we can to improve TinyMCE first.
Vitor Carvalho 9:38 pm on December 22, 2012 Permalink
Easier support for other editors would be nice, but is it actually achievable? I mean, there are a lot of new JS editors with different configurations…
I like TinyMCE, in fact neither I nor my clients have anything to say about it.
Erlend Sogge Heggen 12:22 am on December 29, 2012 Permalink
Very understandable, thanks for replying.
Mark Jaquith 7:52 am on December 21, 2012 Permalink
There’s one improvement that I’d like to make, that’s pretty simple: built-in callbacks for some basic input types. Even just handling text input, checkbox, and textarea would cut down a lot on the slog. Happy to listen to other suggestions.
Vitor Carvalho 9:30 pm on December 22, 2012 Permalink
It would be nice to have a WP_Form_UI class with some methods to handle form elements and merging it with Settings API for easier creation of pages and subpages in the admin. For example, one could create a page just extending a WP_Admin_Page class, as we already do with WP_List_table.
wycks 10:02 pm on December 30, 2012 Permalink
This would be a massive benefit to developers and WordPress itself. Right now custom field wrappers are one of the most popular items on github for WordPress, making a more uniform API that covers those more constantly and integrates with internals would be very nice.
Ronald Huereca 12:55 pm on December 21, 2012 Permalink
@markjaquith, would per-thumbnail editing (as defined in the theme add_image_size) ever be part of core? Right now it appears plugin territory (e.g., http://wordpress.org/extend/plugins/crop-thumbnails/), but would be nice if this were built into the new 3.5 image edit area.
Marko Heijnen 7:50 pm on December 27, 2012 Permalink
I think for 3.6 this still would be plugin territory. There are some other things to address first to get to a per-thumbnail editing mode.