 | newtonsongbird on Suggestions |
 | Kim Parsell on Core Contributor Handbook |
 | Lance Willett on We’re getting very close… |
 | Muhammad Abdi on Core Contributor Handbook |
 | Maor Chasen on We’re getting very close… |
Heya. Now that we know Mark will be the release lead for 3.6, on with team rep voting results. 
Part of why I wanted to wait was because the people with the most votes were Nacin and Jaquith, and I suspected Jaquith would be leading 3.6 (so he shouldn’t be team rep also, per earlier discussions).
Core team reps: @nacin and @scribu. Woohoo!
Term begins with the new year and goes through June.
For some time (since r10291), WordPress has shipped minified scripts and styles as .js and .css, with the non-minified, “development” versions at .dev.js and .dev.css.
These weren’t great for discoverability and it has become clear that these are non-standard. So, we’ve moved to using .min.js and .min.css for minified files. You can now find the “development” versions at .js and .css. This also works nicely with tools like ack, which are coded to ignore .min.js.
This was implemented in #21633. Now if only we can get TinyMCE to move away from _src.js.
A note, for some external libraries, we don’t include the un-minified versions. In this case, you can find them on their respective websites and also in the sources repository. (This is linked from wordpress.org, which in turn is referenced at the bottom of our license file.) @scribu and I were talking about writing a developer plugin to use un-minified versions of these libraries, which would be cool.
More on external libraries in 3.5 here.
Perhaps you could use the existing Developer plugin? http://wordpress.org/extend/plugins/developer/
Japh, that’s pretty cool idea: https://github.com/Automattic/developer/issues/22
I like the fact that you posted this.
Skunk Works … document things, and leave your engineering journal open on your desk.
#culture
I once wrote a plugin to do this for the TinyMCE files, it was not too hard. Don’t know whether the hack will work for current versions of WordPress (because TinyMCE did not use wp_register_script(), I had to use another hook).
I’d like this week’s dev chat to be a discussion about the 3.1 release cycle. We all know it came out around 2 months later than planned, but why? What went well, what could have gone better, and what should we learn from this release and try to improve with our processes for 3.2?
Definitely happy to see this topic — actually considering my recent comment at wordpress.tv the timing is uncanny 
Was it just 2 months later than planned though? As I recall, the end-of-2010 deadline was itself a postponement of an even earlier date. I guess that was also a result of 3.0 being delayed, but that just makes it an integral part of this discussion.
http://replay.waybackmachine.org/20100527203256/http://wordpress.org/about/roadmap/
Nope. It wasn’t a postponement of an earlier date at all. We decided to take two months off to focus on wordpress.org community infrastructure (the cycle we were calling 3.org), and that just didn’t have a place on the roadmap, so the roadmap was out of date, that’s all.
Oh right! My bad. Yeah I remember those two months, it was a very welcome move, and a bunch got done
Hi, what abou to make a banner, which says to help to WP community. Maybe we shall also think about how to make developers glad (money…………..VIP section) to make patch for us.
By the Way : Glad to see you here back
Agreed, I made a couple suggestions along those lines back in the “What should 2011 hold ..” post – see “Acknowledge contributions”.
Though, I think this is a somewhat different topic. Developer appraisal is quite s separate issue from “what can 3.2 learn from the 3.1 release cycle”.
of course you are right, BUT : if we want to change somethink ( read: “what can 3.2 learn from the 3.1 release cycle” ) we have to start to think what we already had made wrong.
Examples are :
1.Forget to write a roadmap with dates. Same like Blizzard does.
2.Pay people, or don’t, if they finish their work or not. Exception for @Nacin a @scribu + some others
+
+
+
There are several reasons why Blizzard doesn’t publicize/use a roadmap, but hardly any of them apply to WordPress. Blizzard and WordPress (or Blizzard and Automattic for that matter) are largely dissimilar.
Structurally speaking, WordPress is very similar to Ubuntu, which has got an exceptionally steady release cycle that has no doubt been in their favor.
A successful release cycle is more about meeting expectations than it is about getting tons of stuff done. If you promise too many things, you trap yourself in a release cycle that’s based on work that needs to be done on time. If you promise only a few things, you’ll have a much higher chance of delivering on your promise, and you’ll probably get to surprise your users with a handful of bonus additions that made it in in time for release.
Very well put.
Thanks, I think. See, here’s an inherent problem of WordPress threaded comments:
To not make a mess of threads (in this case we seem to have also reached the limit of threading) I usually reply in the same way, that is in this case, reply to Malcjohn in order to make my comment appear directly below yours. I’d like to think you meant to reply to me, however my e-mail notification said you were replying to Malcjohn.
There logic of the commenting system is a tad flawed. Figured I might as well point that out here since the example use case is right under our noses.
3.2 > PHP5 > WordPress Object Oriented code
will help for sure !
Following up on @scribu‘s post with further rationale and the 31compat tag.
The many problems. When plugin upgrades were introduced in 2.8, the activation hook fired for them. The deactivation hook did not. This was inconsistency number one.
When bulk plugin upgrades were introduced on the Tools > Updates screen in 2.9, the activation hook did not fire (during the bulk upgrade). This was inconsistency number two.
Bulk plugin upgrades were given greater prominence in 3.0, with the Updates move to under Dashboard, and a new bulk action on the plugins screen. This made the second inconsistency far more prominent.
Additionally, activation hooks could always fire on activation, because that has to be done through the admin, but updates don’t. Updates done manually (including SVN) was just one more instance where we may not have been firing updates. This was inconsistency number three.
We felt that the proper fix was to prevent the activation hook from firing on any upgrades, bulk or not, as this was not intuitive. Sorry if your plugin relied on this undocumented behavior.
The theory behind the right way to do this. The proper way to handle an upgrade path is to only run an upgrade procedure when you need to. Ideally, you would store a “version” in your plugin’s database option, and then a version in the code. If they do not match, you would fire your upgrade procedure, and then set the database option to equal the version in the code. This is how many plugins handle upgrades, and this is how core works as well.
The right way to do this. I would do what many other plugins do and do the upgrade procedure as I described, and as Peter and Andy described in the previous post.
Further reading. You can read more about this issue, on ticket #14915.
Even though that’s certainly a way to accomplish the same thing, the logical solution would be to make another hook for activation.
Which would not run for manually upgraded plugins. Hooks for upgrades is a non-starter. Plugins have to do it.
I would guess that most plugins are automatically upgraded, making this a simple solution.
Many people use git or svn, and relying on a hook is not multisite compatible.
Thanks for explaining that Nacin.
I’m currently misusing the activation hook – my activation function includes all the update logic I need. I’m aware it doesn’t work for FTP updates, so my update instructions tell people to deactivate and then reactivate the plugin. Of course, that won’t work for SVN updates, which I hadn’t considered (although with due respect to Ryan, I’d argue that not many *average users* would update via SVN).
If the logic needs to be handled via the plugins, that’s fine, I’ll update mine. In fac,t I used to handle it in the plugin but removed it because I figured that running something just on activation would be more efficient that checking the version number on every single page load. For one plugin, not much of a drama, but when you start having 30 plugins all checking their version number on every page load of the site… But if that’s what we have to do, then that’s what we have to do.
It’s not inefficient for every plugin to store a small amount of data in the options table. They will all be automatically loaded with a single query. The overhead added by a single, small row is small enough to ignore.
Agreed.
Also – you should try really hard to ensure your plugin still works even with the old settings until the upgrade had happened unless it can be done without user interaction.
In most cases if you need user interaction you can trigger an admin_notice on the next page load after the update.
If you have a update that takes a while consider using a wp-cron “job” to do the migration work.
Thanks for pointing that Andy.
I was assuming a separate DB call for each plugin’s options entry. I knew the core options were bundled into a single DB call, but was under the impression (from heresay, not anything resembling facts) that non core options weren’t included and needed a separate DB call.
And Peter, yes, you’re right of course, the plugin shouldn’t rely on something existing that may not be there. I code properly *most* of the time, but I guess I’ve leant on the activation hook crutch occasionally. I think I need to spend some time with my plugins and make sure I’m not making the problem I’m complaining about
@Stephen: As long as you ask for your option to be autoloaded when registered it comes in one query with the rest of the autoloads
Just a note regarding autoloading of options:
By default, autoload is set to yes for all options added via add_option. So, other than adding your option, there is nothing you need to specify if you want it to be autoloaded.
More here: http://codex.wordpress.org/Function_Reference/add_option
Hi, just a quick note to point out that this documentation page is still giving wrong instructions for plugin developers: http://codex.wordpress.org/Creating_Tables_with_Plugins
Cheers,
Jarkko
I am VERY late to this party, but when I manually de-activate a plugin, and then reactivate it again manually, won’t fire the “acivation hook”? Seems a little stupid. Also makes testing my plugin a huge pain.
Even later to reply to you — If you manually de-activate and manually reactivate, yes, it fires the activation (and deactivation) hooks. This was only for core’s one-click updates — when we update a plugin, we do not fire an activation hook.
Attention all plugin authors:
If you were using register_activation_hook() to also handle updates from older versions of your plugins, you will not be able to do so any more in WP 3.1: [16012]
The activation hook is now fired only when the user activates the plugin and not when an automatic plugin update occurs. This is consistent with how the deactivation hook works.
There is a proposal for a register_update_hook() instead: #14912
Also, the callbacks for de/activation can now accept a network activation flag:
Argh! I do not like this!
I don’t have a good grasp of the issue, but I somehow feel we shouldn’t remove this feature, even with its current inconsistent behaviour, without having something to replace it first.
Why not wait until we have an update hook?
It’s not a feature, it’s a an inconsistency that leads to obscure bugs.
As for the update hook, please lobby for it’s inclusion then.
It is a bug pure and simple and this fixes it.
argh. darn dagnabit. better change my update routine then. I’m so relieved I did some changes in preparation for this, it’s going to catch a lot of plugin authors out though.
actually quick query, what is the best thing to hook onto for updates at the moment? init?
That is what they get for holding it wrong.
Relying on a hook for update detection is not a good ideatm as there are too many scenarios in which is won’t fire.
Good plugins would use something similar to the $db_version that core uses itself.
For ages I have used a constant and bumped it only when the updated plugin will need to run some upgrade code. I agree this is the way to go.
“Good plugins would use something similar to the $db_version that core uses itself.”
I would agree if you said “Perfect plugins”, because I know of good plugins that rely on this inconsistently fired hook to run their upgrade code.
I think the problem I see with this change is that we remove something people use without telling why it is removed and what should be used instead.
If an update hook can never be reliable (because plugins are often updated through channels of which WP cannot be aware), then we should wontfix that ticket and tell people clearly that the only reliable method is what you and Andy describe.
I think the problem I see with this change is that we remove something people use without telling why it is removed and what should be used instead.
We announced it here and described the reasons for it.
We also suggested a fix.
If an update hook can never be reliable (because plugins are often updated through channels of which WP cannot be aware), then we should wontfix that ticket and tell people clearly that the only reliable method is what you and Andy describe.
The register_update_hook() proposed is exactly what westi and Andy describe, so it is reliable.
In conclusion, please check your facts first.
If I understand correctly, the feature is removed because it cannot be relied upon: the hook is fired in some cases, but not in others. This announcement says nothing of the sort.
The fix suggested is slated for a future release (and we are now into feature freeze). What are people to use for 3.1?
About the way register_update_hook works, my apologies. I had not looked at the code and, going by the function’s name, I thought it was a hook. But it is not a hook. It is not hooked on to anything. It is a helper function that, as you said, does what Peter and Andy described and that runs everytime the admin is loaded.
(Which does not provide for all scenarios: If I don’t update via the admin, the update code will not run until I visit the admin.)
To clarify, the activation hook can’t be relied upon for updating. Makes sense?
Furthermore, it’s not removed, just restricted to it’s intended purpose.
Also, we still have a few days until feature freeze, so I’m hopeful.
Anyway, register_update_hook() doesn’t require any other core modifications, so plugin authors can just drop it in their plugin, wrapped in an if ( !functions_exists() )
According to the schedule, feature freeze was on the 15th of October:
http://wpdevel.wordpress.com/version-3-1-project-schedule/
In any case, I think an extra post explaining all this would be useful:
A.
We don’t fire the activation hook anymore on plugin updates because it was not reliable for update detection:
1. It did not work for bulk updates
2. It did not work for network updates
3. It did not help for updates not done via the admin
B.
The reliable method for update detection is [what Peter and Andy described].
C.
[What we say here depends on whether register_update_hook makes it into 3.1.]
I meant to say primary code freeze.
Anyway, nice summary.
+1 to using a constant/variable. I’ve always stored a version number in my settings array and when I loaded the settings, I checked the version and did an upgrade if need be.
Relying on a hook is poor form in general.
I’m thinking this should be a simple s/register_activation_hook/register_update_hook for 99% of plugins that will be broken, assuming register_update_hook makes it into 3.1
Yeah, the only thing would be that register_update_hook() requires a version too.
Reading this and Nacin’s post really helped clarify this. It does make sense to not expect activation hooks to handle upgrades. Especially if a plugin is not deactivated on upgrade (svn, ftp etc).
Excuse me while I go make updates.
Is there a way to avoid an automatic plugin update ?
Yes. There’s a plugin called something like “No Plugin Updates” that does this. You should check it out.
This really did catch us out, I’m sure we won’t be the last. Shouldn’t the automatic update process stop displaying misleading messages such as “Deactivating the plugin…, Removing the old version of the plugin…, Plugin updated successfully, Reactivating the plugin…
It doesn’t say “Successfully fired activation hook”, so it’s not misleading.
You are pulling my leg aren’t you?
Only partly. Read the discussion again (including the one on trac).
We lost all of our comments by updating the plugin.
How can we stop this happening in the future apart from not updating?
This is not the best place to ask. Please use the support forums: http://wordpress.org/support/ (remember to actually mention the plugin name).
Hello,
Had a question about testing my changes to my plugin’s upgrade routine once I’m done making those changes.
I don’t want to push an update (the next higher svn tag) to my plugin’s SVN repo on WordPress just to test how an automatic update would behave. Do I simply just downgrade my live wordpress to the lower version of my plugin and then with filezilla ftp , just copy over the newer version of my plugin ?
thanks for the info above
Steve
You can ignore that. The obvious solution to testing the auto upgrade (without pushing a newer version that I didn’t want wp users to download) is to simply install a version going back to two versions to my WordPress blog, and then I can test what the auto update does after tweaking my current version a little.
Steve – That’s not really a question for this post You could either post in the support forums: http://wordpress.org/support/ or email the hackers list: http://lists.automattic.com/mailman/listinfo/wp-hackers
But basically if you wanted to test an upgrade, and knowing that the activation hook is called “when the user activates the plugin and not when an automatic plugin update occurs” then you really don’t even need to downgrade. I would upload the plugin as trunk and NOT make it the release version, then download the ‘development’ version from http://wordpress.org/extend/plugins/YOURPLUGIN/download/ and use the zip-uploader in WP to upgrade it.
If you need more help on doing that, post on the forums or mail hackers, please
Last night’s dev chat was the first of two planning meetings for 3.1. The intention of this meeting was to remind everyone of the goals for 3.1, identify features that the lead team has prioritized, get an early sense of who’s willing to work on what, and to talk about the timeline. Much of what is written here is what was posted in the dev chat last night, to retain consistency.
There were a lot of suggestions on the table. That said, quite a few suggestions fall outside the stated intentions of 3.1 (quick, fast dev cycle, no big huge projects). For anyone late to the party, here are the goals of 3.1: to have a very short dev cycle, a decent amount of testing time, and a release in mid-December. Low on new features, heavy on ui and code cleanup, and avoidance of schema changes. Save the big ideas for 3.2 where we’ll have the liberty to implement those ideas in PHP5. No schema changes and no big new APIs.
This means stuff that got worked on over the summer or can be taken more or less wholesale from a plugin or patch has a better chance of being allowed into 3.1 than a brand new idea that doesn’t already have code written. In cases where we can do something small in 3.1 to pave the way for something bigger in 3.2, that will be the approach.
To that end, the leads have identified some of the suggestions, both from the wpdevel and from other sources such as the ideas forum/WordCamp feedback/support forums, that would be appealing to include in 3.1. We’ve also identified some things that definitely do NOT fit into the scope of 3.1.
An example of something that doesn’t fit:
Media overhauls. We’re going to target 3.2 for a bunch of media fixes. The underlying code is too complex to do anything hardcore this fast. The only media things that would be acceptable in 3.1 would be small updates that don’t change the overall flow, such as the request to make the caption able to hold html to include links. If someone volunteered to code that, that addition would be acceptable in terms of scope. Other discrete things like this would work. Refactoring the way featured images work would be out of scope.
Another thing that doesn’t fit is per-post/page/category widget selection. There are plugins that do this, and the code is nuts underneath. We want to stick to easy wins for 3.1.
Now on to things that fit!
Polishing features introduced in 3.0 can be one umbrella task. BUT — this means spit and polish ONLY, not adding features to features.
New feature: Mark Jaquith is committed to getting in some advanced taxonomy queries stuff, which already has some movement in trac via scribu.
Mark Jaquith also wanted to get down and dirty with roles/caps, but that’s just too big an undertaking for 3.1. Maybe in 3.1 we could do the get_users() and friends cleanup that scribu started on to pave the way for role cap cleanup next time around.
In short? Mark Jaquith and scribu will be joined at the hip this cycle.
New feature: Internal linking. This is my pet user feature for this release. It has been requested from users for years, got the most +1s on the wpdevel post last week, and is a missing piece of true CMS functionality. Since we likely won’t have Andrew Ozz for this release, Daryl Koopersmith is going to take a stab at this, with backup from Austin Matzko if needed.
New feature: The ajaxified admin screens that scribu did for GSoC, with some UI cleanup applied. There was also a GSoC project by Matt H on comment moderation that needs to be reviewed for inclusion.
New feature: Admin Bar. Connect the back end to the front end. Most useful for people on multisite installs, but still useful for single-site users in providing 1-click access to dashboard, new post form, etc. We’ll be looking at both the original Viper007Bond admin bar plugin and the wordpress.com revised admin bar recently done by Andy Peatling. Note: there was some resistance to this being in core rather than a plugin. A compromise of making it optional was discussed.
Cleanup: UX/UI cleanup across the application, including multisite. This could turn into a ton of new dev, so we need to restrain ourselves. The UI group will do a review and come up with a list. Jane Wells and John O’Nolan will manage UI contributions from the group so that approved UI makes it into tickets.
Ongoing maintenance: Bug fixes. Peter Westwood is all over bug fixes. Anyone and everyone invited to submit patches for known bugs.
New feature: Separate network dashboard from the site dashboards (in multisite). Ryan started on this over the summer, and all agreed it would be great. Needs some UI love. Ryan also looked at doing a personal dashboard to replace the wonky global dashboard you get in multisite when someone has an account but no site. This might be a better 3.2 candidate, but we’ll see if we can get it to a reasonable place in time for 3.1.
There are some small fixes to the custom post types API that ought to be made, while staying within the ‘no big API things’ guideline. Nacin is taking charge of this.
I’d like to swipe the wordpress.com UI for searching/browsing installed themes, as it’s better than what we have in core (especially useful for multisite and sites with lots of installed themes, like those on shared hosting). I helped on the UI when John Godley made it last year, so I’d be comfortable with almost a straight swipe.
New feature: Post templates/post styles. Ryan will be handling this one.
New feature: Making QuickPress a template tag, so it can be used for front-end posting. Aaron Jorbin will be handling this.
Other suggestions not on this list that fit into the 3.1 guidelines (no schema changes, no big new APIs, etc) will be considered until feature freeze if a well-tested patch has been posted by then. Well-tested means more than one person, so if you want your pet project to be considered for 3.1, publicize your patch and get people to test it and post their results to the trac ticket! If you do not take on this responsibility, please do not complain if your patch is not considered; tested patches will always get priority.
We want to release mid-December, preferably no later than December 15, so that the holidays won’t interfere with the release. To that end, here is the current plan:
September 9 – Confirm planned scope.
October 15 – Feature freeze; no new features added after this point, so that testing can begin on a stable-ish product (including usabilty testing of new features).
November 1 – Primary code freeze; any last adjustments based on testing after feature freeze should be finished by now and the focus shifts to fixing bugs to get to a stable beta.
November 15 – Beta period beings; from this point on, no more enhancements, only bug fixes.
December 1 – String freeze; translators rejoice.
December 15 – Release WordPress 3.1
So that’s the current thinking. The leads will be reviewing existing tickets and patches this week and working out the feasibility of including all the items outlined above. Next dev chat should see a conclusion to 3.1 scope planning, with some firm decisions on in/out and dates.
I’d like to help with the UX/UI cleanup. Where will the UI group post this list once they do the review?
You will want to follow the UI blog at http://make.wordpress.org/ui and/or join the weekly IRC meetings in #wordpress-ui at irc.freenode.net.
Is anything planned regarding option pages? I find them quite dull and messy compared to other much more lively pages such as… all the others actually.
Agreed, and they’ll be included in ux/ui review, but whether or not/to what degree they will be touched will depend on how many people volunteer to write the patches once we have approved wireframes.
“New feature: Post templates/post styles. Ryan will be handling this one.”
What is this? Can someone provide more information on this new feature as it was discussed?
The full discussion is in the IRC log. Link is in the right hand sidebar.
“New feature: Admin Bar. Connect the back end to the front end. …. Note: there was some resistance to this being in core rather than a plugin. A compromise of making it optional was discussed.”
Of the 2 possibilities, I prefer the current wordpress.com admin bar.
Please make this optional, default is off. That way users that want it will have to enable it if they want it.
> Please make this optional, default is off. That way users that want it will have to enable it if they want it.
+1
+1
+1
I don’t think there’s anyone arguing that it shouldn’t be optional (i.e. you can’t turn it off).
There might be some arguing that it should be on by default, but I personally think it should be off by default as well.
As for in core vs a core plugin, I haven’t made my mind up about that one.
Oh, and yes, I wouldn’t recommend using much of the code behind the scenes of my plugin. It’s rather dated and messy. It’d be much better to stick to stealing ideas and concepts from it rather than code implementations (giving it a code rewrite has been on my todo list for a while).
It would be really nice if it could be the plugin that finally kicks off the concept for core plugins that we’ve been waiting for since announced.
I’m sure there was a lot of discussion around the whole idea and that if it’s made it in, it’s made it in. Nevertheless I think the logic escapes me (even after a brief review of the irc chat) why an admin bar would be more functional to CMS usability than something such as, say, the front end editor.
I’m sure I’m not an average test case but out of the last couple dozen WordPress powered sites I’ve set up, it has never once crossed my mind that a front end admin bar would be a snazzy addition. +1 to it being optional and turned off by default, +1 to it having an uninstall feature.
Admin bar is first step toward a front-end editor — think long term.
Front-end editor, did you say? It would be awesome to see functionality like this integrated into core at some time in the future. (Of course, it’s a scribu project.
Agreed, the WP.com admin bar seems to be the way to go, considering it was only recently rewritten as well (apparently).
Definitely agreed on making it optional, and I think a core plugin is the best way to go on this.
For the record, the bug for tracking this is #14772
What is the “internal linking” stuff about exactly?
https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2010-09-02#m176561 has a bit of an explanation. Apparently it’s similar to this: http://wordpress.org/extend/plugins/link-to-post/
I wanted ask the same question too.
Linking to another post/page/category from the WYSWIG without having to grab the URL from the public site.
Thanks for the clarification
Thank you. Yes, that is a really needed, I agree.
Would this be problematic on sites and blogs with way too many posts and pages?
AJAX-based search, plus a list of recent posts. Similar to menus.
I could be wrong, but I thought it was going to be something like RB Internal Links http://wordpress.org/extend/plugins/rb-internal-links/ which has been more than useful on a number of occasions.
It’s not going to be specifically like any of the existing plugins that do it. We’ll review existing plugins and put together an interaction model that works best and is in line with core. Whatever inspiration and/or code can be had is great, but none of the existing plugins are exactly what I want as a starting point for the UI.
Whoops, I posted about that plugin just now in #11420. Thanks for explaining the thinking behind how this will happen, Jane.
Are there a trac tickets for “advanced taxonomy queries” and “small fixes to the custom post types API” that detail scope? Thanks in advance.
Start here for taxonomy queries, and post types API.
This is a great start! Would also love to see the sticky post option & custom permalink structures enabled for custom post types.
Another one is adding a simple post type drop-down on post edit write panels. Basically bring in this plugin. http://wordpress.org/extend/plugins/post-type-switcher/
I’m going to be looking at the first two ideas for 3.1. But I don’t foresee a post type switcher ever making it into core. Not every post type is publicly consumable content that can easily be traded off. Some might rely on specific fields, values, meta, not to mention term/taxonomy relationships, and offering a UI for that can easily break things. Keep in mind there’s no UI for post types anywhere, nor are there any plans for that to occur. The UI (same goes for the user) makes no distinction among post, page, event, employee.
@Andrew: Point of note, non publicly consumable content will have their public argument set to false so it would be easy to exclude them from content switcher so I wouldn’t see that as a viable concern. Even better, “allow_type_switch” could be added to “supports” enabling only explicitly approved content to be switched. Posts and Pages could be set as such and then developers could choose which custom post types they wanted to enable switching. Such an approach would assure pretty much no breakage. And let me go on record to say that the team will eventually add UI features for post types because 80% of users will demand it (just sayin…)
@Andrew, great. Those features will be welcome additions. For the custom permalink structure I recommend it can either inherit the WP defined one or you can create a totally different structure.
I see what you mean about breaking things with a post type switcher. Even though it’s complicated, I have to agree with Mike that eventually people will request it. Guess it will have to wait until then.
No mention of the accessibility that jorbin mentioned?
Considering that Matt is a member of GAWDS (Guild of Accessible Web Designers) perhaps this should be a bit more prominent I’m also surprised you haven’t contacted any of the GAWDS admins about accessibility, especially as one of the forum moderators, esmi, is a GAWDS admin….
But if jorbin is reading, feel free to drop me an email as I have experience in reviewing sites for accessibility and could help out as well. I’m just not that ofay with trac/patches etc, but would be willing to work with someone who is to get the ball moving.
Accessibility isn’t a discrete new feature, which is why it isn’t called out separately but falls under the umbrella of ‘anything that can be written/tested/submitted before freeze.’ Accessibility patches will be reviewed and added anytime someone submits them (assuming they are up to par, of course). The problem is that very few people choose to submit accessibility patches. Accessibility patches welcome.
bleh, that means I’ll have to learn how to do patches correctly – well when needed anyway, accessibility usually involves a lot of discussion.
As the accessibility list is dead I’ll ask here, which would you prefer I looked at first, the Twenty Ten theme, or just dive into the admin pages?
Jorbin and I met the other day with an accessibility expert who is local and we agreed that we should definitely try to audit what we can. It’s a very intensive task but patches are *always* welcome except really late in the cycle.
I’d like to look at both. Having TT accessible will be nice, with the admin being higher priority (but more difficult).
Well I’ll start with Twenty Ten then That’s actually more static than the evolving admin backend anyway. So should be slightly easier to assess. Well hopefully.
I’d actually say the front end is more important than the back end, but with the number of different themes out there, it’s slightly skewed. It’s also a good way to test the water, see how changes are accepted etc.
Also it has to be realised that different people will pick up on different things, accessibility isn’t as always a clear cut case.
And yeah I saw that you’d had a meeting in the chat logs (see someone does read them).
But remember the best way for accessibility auditing, is to use pan disability testing. I do know of a few but obviously their services, in the main, are not free.
A big ‘doh’ from me re patches, let me never complain about them again.
Made a start with Twenty Ten, just concentrating on links ‘mainly’, adding other bits if I come across them. Will submit a patch for CSS only when done.
@Rich: I would say look at the admin first, becaase Twenty Ten can be updated anytime, not tied to a release schedule. I will say that in previous releases we have had volunteer accessibility professionals review the admin through their systems once we get to the beta stage, and we fix anything they tell us is an issue. As you say though, different people will turn up different things.
as far as i see new “The ajaxified admin screens” will break a lot of plugins admin pages ( #14651, #14776 )
There should be no backwards compatibility issues when we are done. Any regressions are potential blockers. cc @scribu.
Might be too late to suggest this, or maybe the wrong place now that the dev chat and discussion already occurred, but:
– Once that’s done, consider using the autocomplete that’s built into the latest version rather than suggest.js (http://core.trac.wordpress.org/ticket/12399)
We’ll be updating jQuery UI, but no plans to utilize autocomplete. We don’t use it anywhere in core, and suggest.js has served us well. Seems like an unnecessary refactoring.
No taxonomy meta table?
There are a lot of fine work going on out there among plugin authors, using custom post types with custom taxonomies. These are grets features that developed WordPress into a completely new dimension.
Bu we MUST have a way to store meta data about a taxonomy id, like contact info, price scheme, valid, periods of validity an so on foremver. Now every athors invents their own method of storiung this data.
Couldn’t WordPress core just define and create a tax_meta table for 3.1. I mean, without doing anything with it, Just lket it exist there for plugins, at least until 3.2?
Or could we have an “officially” proposed table name and layout for this, something that plugin authors could implement an create, if not already created?
Having ten plugins that all impelement their own prorietary metadata table is not a good situation, at least not the day WordPress core wants to implement one, too.
I would say tha ta taxonomy_meta has become a “core necessity” and it’s quite urgent.
+1 on a revisiting the idea of a taxonomy meta table here. Lots of requests here and almost all of the code needed is already in 3.0 so scope is very small. Doesn’t need a UI yet, just needs to be there for plugin and theme devs.
Not for 3.1, but we’ve talked about publishing a “If we did it” post. So I’ll get going on that.
That post definitely needs to be written, and it needs to be “official.” I’ve gotten multiple questions relating to this on a weekly basis for over a year now from users. The only reason I haven’t implemented it myself is because I don’t want to deal with upgrade issues if core goes in a different direction in the future.
That’d be exactly the idea.
Just curious. If you can write an article about how you’d do it, why not just do it? From what I understand 90% of the code is already in core, right? (This is an honest question; I’m just trying to understand the need for delaying until after 3.1?)
Can I cheekily push forward this media suggestion (in the knowledge that full media overhauls are out of scope)… just *three* filters! http://core.trac.wordpress.org/ticket/13817
+1 to this ticket. After all as Simon says, it’s only three *filters*.
To clarify, is http://core.trac.wordpress.org/ticket/12877 making it into 3.1? (specifically, searching for page templates in sub-folders?
It’d be awesome to swipe the wordpress.com method for searching already installed themes. I run a WPMS install and right now it’s a pain to manually dig through 60+ themes.
Any chance of getting a simple ‘hide’ checkbox in the custom menu admin so that if you want to disable a menu item temporarily you don’t have to delete and add again. Reason I ask is that every time you do that it gives you a different css class which means, if you’re reliant on those classes for your styles you have to fix the css every time. Which also means that my clients are dependent on me to do this for them.
Probably not in 3.1. We’re pretty resolved to not touch the menu system until 3.2. You’d probably be better off writing a plugin for this right now, and if it becomes popular, we can consider the functionality for core in the future.
I am not clear with internal linking. What is it?
I was developing something that required the query for multiple Custom Fields, and when I was reading this I thought that Is a old request (http://bit.ly/cuujoQ). And there is any chance that will be coming any time soon?
Thanks alot,
Today in #wordpress-gsoc, it’s @nacin at 19:30 UTC (Theme revisions/editor project) and @scribu at 20:30 UTC (ajaxify admin). I will hopefully be there, but if my flight doesn’t land on time, go ahead without me and I’ll read the logs afterward.
Unfortunately to to some major, unexpected changes in my travel plans I cannot host today. Will talk with Jane once she’s grounded and will try to set up a time for Tuesday or Wednesday.
Monday, August 9, 2010 at 20:30 UTC (4:30 eastern), @scribu will present his GSoC project, which was to ajaxify a number of admin screens. To hear about his project, ask questions, give feedback, etc, join us then in #wordpress-gsoc on irc.freenode.net.
Hei, the @ mention feature is pretty nice. Is there a plugin for it?
Found out it’s baked directly into P2.
Yep, last version.
Suggest agenda items for July 22nd 2010 dev chat
3.0.1 ETA. Unless I missed a previous discussion about this…
Clean up Trac components. There are a lot of overlaps.
Upload – should be either ‘Media’ or ‘Filesystem’
Rewrite rules – use ‘Permalinks’ instead
Template – what does that even mean? use ‘Formatting’ or ‘Themes’ instead
Optimization
Performance
JavaScript
Import – no longer in Core
Blog by Email – feature to be excluded from Core
It would be good if each component had a description in the Codex, above Trac Keywords
mu.wordpress.org is still up and running, offering an old version for download. We should redirect to a page on the main site that talks about MS or something.
People with older than 2.9.X MU installs need to upgrade to 2.9.2 before they can auto upgrade to 3.0. So, some access to mu.wordpress.org has to be left open.
Fair enough, but what about new users who have found a guide saying go to mu.wordpress.org ?
EDIT: the page on the main site talking about MS could have a download link to 2.9.2.
We need to move the MU release archive over to a page on wordpress.org. (Which, really, does not exist on mu.wordpress.org — there are simply links to Trac.) Docs already is a single page going to the Codex (and is out of date). About is a single page and out of date. The forums remain for archival purposes but the top link now goes to the Multisite forum.
Then, I suggest we replace the entire site with a single splash page.
Suggestion: a landing page, trumpeting that MU is now MS, pointers to tutorial for upgrading, and core WP download links.
+1
mu.wordpress.org download links now redirect to wordpress.org. The full MU release archive is now part of the WP release archive and listed at /download/release-archive/. /forums/ remains in place for posterity. All other pages redirect back to the mu.wordpress.org front page which is now a simple landing page.
There’s a problem with the “Create a Network” link.
@scribu: Fine to me.
Yeah, it’s fixed now.
Well done!
arena, and 2 others are discussing. 
+1 on the idea of a dev plugin to use un-minified versions. Perhaps just a way to pull them automatically from the original source if SCRIPT_DEBUG is on?