As 3.1 winds down and early 3.2 development is likely to start soon, I’m trying to make Trac a bit more usable, ranging from reports to the theme itself.
I’ve been tinkering with report 40, Tickets Awaiting Review. It now uses the type of ticket, version it was reported against, and keywords, to create five groups of tickets:
- Defects Awaiting Review, reported against trunk (or no version number specified)
- Defects Awaiting Review, reported against latest branch
- Defects Awaiting Review (all other bugs)
- Enhancements Awaiting Review (includes feature requests)
- Reporter Feedback / Close (tickets marked for reporter-feedback or close, which overrides the other groups)
Each group is then sorted in descending order from when the ticket was last modified. Right now the first two groups are the same, but I’ll modify the report once 3.2 development starts.
Ideally, this will allow us to better track and triage incoming tickets. It also increases the significance of the ‘Version’ field (version it was reported against, but ideally earliest version to which the ticket applies) and removing reporter-feedback when feedback is provided.
I’ll be working on report 39 (Candidates for 3.2) soon. Suggestions welcome for improvements on both.
Tomas Kapler 10:44 am on February 8, 2011 Permalink
I have noticed your recommendation to theme and plugins developers to test their themes/plugins. It would be great, if you would ask them to test it with wp-debug set to true. In last few weeks i have tested about 40 plugins, most of them with 4-5 stars and from recommended/most-downloaded group, all of them updated in last months, not old, but more then half of them throws a lot of warning notices as they are using obsolete functions (some of theme obsolete even from wp 2.0 version!), updating not-set variables etc. I have informed their developers, but i can’t do it for 13000 plugins.
Andrew Nacin 12:42 pm on February 8, 2011 Permalink
First, thanks so much for testing all of those plugins — that helps a lot, even just to boost my confidence in 3.1.
I also appreciate that you’ve informed developers when you’ve seen issues with notices. That’s a great way to contribute back in the community.
The issue I think is a bit more complicated though. While we try hard to avoid notices, core is not without them. On occasion it isn’t without deprecated behavior (usually an argument we deprecated earlier in the cycle). It’d be a double-standard to enforce notices in plugins. Obviously, you’re not suggesting we enforce it, only that we suggest it.
But what we’re really looking for right now is just to verify that plugins and themes aren’t flat-out breaking, which could mean that something in 3.1 has regressed and require us to hold up the release. So right now it’s a much different standard we’re looking for. If I emphasized WP_DEBUG on the main blog, users who turn them on would be overwhelmed. Likewise, developers would see so many notices in their own code, that they would be focused on those instead of real bugs or potentially core regressions — or worse, they don’t bother with testing at all, thinking we’re crazy.
Keep in mind this is coming from one of the larger proponents of WP_DEBUG and cleaning up deprecated usage. We need to be careful of the message we send and when. But heck, I’d fully support an International WP_DEUBG Day maybe at some point in the future.
Debug Bar is looking pretty nice, so hopefully once the panels are cleaned up, we can start to really push its use.
Again, thanks for your thoughts. We really should do everything we can to emphasize debug mode.
Rich Pedley 1:30 pm on February 9, 2011 Permalink
can we have WP_DEBUG Day instead…
Submitted themes have to have tested with WP_DEBUG set, it’s part of the criteria. Plugins don’t go through checks like themes do, and no I’m not suggesting that, but could the plugin they use for themes be adapted for plugins? I’m thinking of testing for deprecated things etc. especially. I know the debug bar has that built in more or less, but that doesn’t cover everything.
Andrew Nacin 1:35 pm on February 9, 2011 Permalink
Well, there’s also a fine plugin called Log Deprecated Notices. Eventually, when it is activated along with Debug Bar, it’ll actually take over and pretty up the Deprecated panel.
You’d be surprised what Debug Bar covers. It handles notices, warnings, and deprecated usage.
Rich Pedley 10:26 pm on February 10, 2011 Permalink
nah you’re missing the point. I’m talking about the automated check that is done. Now I know that themes are handled differently, but could an automated check be done on plugins in the SVN repository for deprecated things?
The more aware plugin developer will be using the debug bar, the log deprecated notices etc etc, but there will be a few that don’t. Or even a few that get missed, having an automated checker at WordPress.org end would help find these, and appropriate action could then be taken – including a temp suspension of that plugin being listed (perhaps)
Andrew Nacin 10:29 pm on February 10, 2011 Permalink
We can’t just do a code scan. The issue is that they might be doing a function_exists(), then gracefully degrading to only triggering deprecated functions if necessary — say, to support older versions of WordPress.
Rich Pedley 12:55 pm on February 11, 2011 Permalink
True, though I wasn’t sure if plugins were going to go the way themes have done – and only support recent releases, hence the suggestion.