Starting next week, we’ll be attempting to follow an agenda during the Wednesday dev chats. If you would like to propose a topic for the July 8, 2009 dev chat, please submit it in the replies/comments to this post. We’ll post an agenda the morning of the dev chat (i.e., about 8-10 hours in advance).
Recent Updates RSS Hide threads | Keyboard Shortcuts
-
Jane Wells
-
Mark Jaquith
Deprecated
clean_url()in favor ofesc_url(), and deprecatedsanitize_url()in favor ofesc_url_raw().-
Lloyd Budd
http://codex.wordpress.org/Data_Validation will need an update.
-
-
Mark Jaquith
Deprecated
wp_specialchars()in favor ofesc_html()(also:esc_html__()andesc_html_e()). Usingwp_specialchars()with more than one param works for backwards compat. Also,esc_html()(orwp_specialchars()with one param) escapes quotes, just likeesc_attr(). This buys security for plugin authors who were mistakenly using a one-paramwp_specialchars()call in an HTML attribute. See this wp-hackers message for more detail. -
Peter Westwood
Trying to keep the commit candidates under control. Every time I look up the list gets bigger.
-
Denis de Bernardy
Yeah, I did some cleaning up and testing.
-
Denis de Bernardy
It would help if they got committed or rejected with feedback faster, btw.
trac wouldn’t be so overcluttered with tickets if commit candidates got looked into on the spot. and contributors would have more incentive to maintain their patches. as things are, a valid ticket can easily be ignored for a year from lack of traction, and that is quite discouraging for contributors.
some oss projects (pgsql) have a bug-to-feedback process of under 48 hours. that helps *a lot* to get the community involved. especially, as is the case of pgsql, when it usually means bug-to-fix.
-
Peter Westwood
We do try to respond as fast as possible. But responding is not a short task and good quality patch review takes time.
You have to make sure that the bug is being fixed in the correct way.
Often lack of detail in the ticket will make this take longer
-
-
-
Mark Jaquith
Standardizing and shortening the WP security escaping functions.
attribute_escape()is nowesc_attr()Additionally, you can do attribute escaping and translation in one go. Just add the translation function to the end. Like so:
esc_attr__()— translate and return, attribute-escaped.esc_attr_e()— translate and echo, attribute-escaped.
Will be following up with
esc_html(with__()and_e()variants),esc_url(), maybe some more. Will be nice, short, predictable, and allow you do translate/escape in one go without a lot of nested parenthesis.-
Viper007Bond
An
esc_js()or whatnot might be useful to (i.e. an improvedjs_escape()(see #7648).-
Mark Jaquith
Yes, I meant to include that in the list of “coming soon” ones. Though
js_escape()would continue to work, as wouldattribute_escape()andwp_specialchars().Improvements to
esc_js()néejs_escape()are a separate issue — I’ll take a look at that ticket.
-
-
Leandro Vieira Pinho
Why not escape_attr than esc_attr?. Write escape is more intuitive than esc.
Andrew Ozz
Going through some of the accessibility improvements. 2.7 was tested with JAWS but there were some changes in the UI since then. Does anybody use JAWS or another screen reader, or know somebody that uses it? Feedback is welcome.
-
Ryan
I do someone who uses Jaws. I’ll send a link to this page to them in case they are keen to help out.
I’ve sent him an email. Hopefully he’ll be keen to help out. -
slger
Is there a list of accessibility items to test? I’ll work on them.
My biggest problem: can’t get rid of archieves. Also cannot see theme well enough to know if it looks ok. What’s the most accessible theme?
-
Ryan
This ticket has some discussion on hidden labels.
-
Lynne
FWIW, I know of a couple of folk who use assistive devices and who cannot use 2.7. As far as I know, they are still on 2.6.5. JAWS is only one of a number of assistive devices and even with JAWS users, proficiency varies. Accessibility with JAWS depends on the users level of experience and also on which browser they are using. EYES has the same issues. Headwands, voice recognition, etc also rely on the site being accessible and, again, these are things most of us can’t test.
Having said that, there are a number of people, including people with disabilities, who are keen to see WordPress become fully accessible. Some just walked away after concerns about 2.7 got fobbed off with the comment that it underwent usability testing and was therefore ok. I pretty much shut up about accessibility at that time too, and although I develop sites for others on 2.7/2.7.1, my own site remains on 2.6.5 because of accessibility issues.
Don’t try to go it alone guys – great coders are not expected to be experts in web app accessibility. If you put accessibility improvements on the roadmap for 2.9 and would consider opening a wp-accessibility mailing list for those in the accessibility field to discuss issues and fixes in, I can get a call out to the Guild of Accessible Web Designers and others I network with and get people working on this.
Just a thought.
-
Glenda Watson Hyatt
Great point, Lynne! Involve people with disabilities who use various assistive technology in to development and testing.
-
Jane Wells
Lynne, who commented that 2.7 underwent usability testing and was therefore okay? Not any of the core team, I’m sure, as we did have someone from an accessibility company do a review for us during the 2.7 dev cycle, and we fixed as many of the things as we could. Usability and accessibility are not the same, and we all recognize that. There’s definitely room for improvement, but we absolutely are paying attention.
-
Lynne
I put in a request through wp-hackers a few weeks back, asking if we could have a wp-accessibility mailing list set up please. There are enough people interested in contributing to development and testing for accessibility that a dedicated mailing list would, IMO, be very worthwhile.
Has there been any decision made on this yet? Accessibility discussion just gets lost in the busy wp-hackers list & that list is not perceived as the most inviting for those whose primary interest is in accessibility issues.
-
-
Lorelle VanFossen
Don’t forget to include Glenda Watson Hyatt of http://www.doitmyselfblog.com/ as she is an accessibility expert, WordPress fan, and living tester of these things. She has top connections, too, to help. @glendaWH on Twitter.
Jane Wells
There was some talk last night about maybe doing a little design brushup on the admin header/nav. We only have a couple of days to decide on the design changes if we want to include it in 2.8. Would like to give community designers the opportunity to do a mockup (could give them a psd of the current style), but since they’d need to submit their design suggestions by Monday, and I’m nervous that there might be some backlash for the short/no notice. I mean, MT didn’t get any notice either, so it seems fair. It’s a pretty small design job… Jaquith did a quick mockup in 5 minutes. If anyone does take up the challenge, we can post the comps for a vote on Tuesday. What do people think?
-
Jane Wells
We decided to do it. Posted on dev blog here: http://wordpress.org/development/2009/04/design-tweaks-whos-in-an-idea-in-three-acts/
Widgets redesign
Andrew Ozz
All of the redesigned widgets functionality is in place in trunk. Only remaining is some improvement to the visual design for the widgets screen in admin.
The new way to add widgets to WordPress is by extending WP_Widget. All widgets created that way have support for multiple instances.
Also all existing widgets will have to be converted to this system as the previous API functions will (most likely) be removed in 2.9. This is quite easy and any of the default widgets can be used as an example.
A typical widget is constructed as follows:
class WP_Widget_Archives extends WP_Widget {
function WP_Widget_Archives() {
$widget_ops = array('classname' => 'widget_archive', 'description' => __( "A monthly archive of your blog's posts") );
$this->WP_Widget(false, __('Archives'), $widget_ops);
}
function widget( $args, $instance ) {
// displays the widget on the front end
}
function update( $new_instance, $old_instance ) {
// update the instance's settings
}
function form( $instance ) {
// displays the widget admin form
}
}
// register the widget
add_action('widgets_init', 'my_super_widget_init');
function my_super_widget_init() {
register_widget('WP_Widget_Archives');
}
For more details and examples check wp-includes/widgets.php and wp-includes/default-widgets.php.
-
GaMerZ
I think you miss out the register_widget() hook.
http://lesterchan.net/wordpress/2009/03/17/new-wp_widget-class-in-wordpress-28/
-
Andrew Ozz
You’re right, that should be in there too.
-
-
amfprod
While we’re at it can we give widgets a RTE?
Denis de Bernardy
It’s really neat, but… Grumble, grumble. Now, I need to rewrite over a dozen plugins that used the old API. I really hope WP 2.8 won’t be released too early. 
-
Viper007Bond
Old widgets will continue to work fine in WordPress 2.8.
Ryan
The plugins management page has been overhauled to better match other management pages. There are status filters for All, Active, Recently Active, Inactive, and Update Available. There’s also search and paging with a screen option for setting the number of plugins to show per page.
Ryan
When on a management page, the Favorite Actions dropdown now defaults to the create page that corresponds to that management page, and vice-versa. For example, visit edit.php and the dropdown displays “Create Post”. Visit post-new.php and the dropdown displays “Edit Posts”.
Jane Wells 10:24 pm on July 1, 2009 Permalink |
I will want to discuss the rankings from the feature poll that we’ll have up by then. It will still be running, but we should have a few days’ worth of votes, which is when we get the bulk of them anyway.
Denis de Bernardy 10:29 pm on July 1, 2009 Permalink |
If I may, it’s going to be much more important to find the volunteers to code the stuff.
Jane Wells 10:56 pm on July 1, 2009 Permalink
True, but we can’t very well assign volunteers to specific feature development if we don’t know the features, and we don’t want to decide features without community input (as opposed to the core devs and or just the dev chat making these decisions). So while finding volunteers is super important and definitely harder than deciding features, we do need to decide the features as well.
Denis de Bernardy 7:35 am on July 2, 2009 Permalink
Indeed, but at the end of the day I tend to remain very down to earth on this kind of thing.
End-user feedback is meaningless if nobody shows up to code their requested features. On the contrary, asking for such feedback can have a negative impact. If those who are coding patches ignore the feature requests and prefer to focus on other things, you end up in a situation where users go “WP Devs ignore their community’s input”.
Thus, please make sure someone’s willing to code feature A, B, C before submitting it to any kind of vote.
Jane Wells 2:12 pm on July 2, 2009 Permalink
That point of view is in direct opposition to the idea of letting the full community have input into our feature set. Worst case scenario is that the core devs code features no one volunteers for and it takes longer, so knowing the priorities of the broader community is imperative in deciding which features they should focus on first.
As with every vote, we make it clear that the vote is to influence core decisions, not to make them, so your argument does not convince me that we should forego voting before assigning developers to features. There’s no point in coding something that isn’t important to the broader community, and we aren’t going to put features in core just because a developer offered to code it, if it’s not to the benefit of the wider community.
Community opinion + technical considerations + developer availability = How core decisions get made. We need all three factors to make a decision.
Matt 4:30 pm on July 2, 2009 Permalink
If something is important and worthwhile, we’ll get it done.
Sometimes that means working on un-fun things but that’s okay.
Peter Westwood 7:22 am on July 3, 2009 Permalink
There is no point coding features that people don’t want just because someone wants to code them – that is just adding bloat
We need to know what the community desires so that we can focus on the right things.
Denis de Bernardy 10:28 pm on July 1, 2009 Permalink |
bugs, bugs, bugs, bugs. there are too many in trac, they need to get fixed/addressed, and there are bottlenecks to getting them tested and fixed. I stand by my opinion on this. the short short version is: need… more… committers…
Matt 4:30 pm on July 2, 2009 Permalink |
We need to be careful as we go through tickets — I feel like a blind chasing of low-priority bugs in the last dev cycle delayed the release and the resulting changes introduced instability we haven’t had in a few releases, regardless of the arbitrary metric of # of tickets in trac.
Xavier 10:39 pm on July 2, 2009 Permalink
True enough. In my 2.8-presenting post on WPFR, I came out hoping that the sheer number of tickets solved was proof that 2.8 was among the cleanest and most stable release since a long time. Turns out that’s wrong, since 2.8.1 comes with a bunch of bugs that (AFAICT) should have been spotted earlier.
While I can’t be against more committers, I’d be also in strong favor of asking for more tests, insisting the original reporter (and participants to the tickets) to make sure an issue is indeed fixed without side-effect, and maybe build more automated & user tests?
Insisting on community leaders to have their staff and community make real-world tests of betas and RCs (with according test plan sheet, even?) ? I’m afraid a lot of us tend to rely on the “hey, core-devs are good, no need to worry. oh shoot, that feature is b0rked. bah, they’ll prolly know about it, it’ll get fixed eventually”.
Typing while thinking, not sure that’s legible. Short version: moar testing.
Peter Westwood 7:20 am on July 3, 2009 Permalink |
Just because there are a lot of bugs in trac does not make the software very buggy.
We need to hit the big issues and deal with some of them each release.
Any attempt to “fix” all the bugs in trac in one release cycle would just make things worse.
I don’t see that adding a huge chunk of committers improves anything.
We need a small number of good well tested patches which hit the big bugs.
A slower more heavily tested and reviewed development process produces more stable software than one where you just chuck all the fixes in you can find and hope they work.
Getting more people involved in things like automated test writing would be a big help – this means we can get good validation on the functionality at a low level which we are building upon