Recent Updates RSS Hide threads | Keyboard Shortcuts

  • Jane Wells 10:23 pm on July 1, 2009 Permalink | Reply
    Tags: process

    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).

     
    • Jane Wells 10:24 pm on July 1, 2009 Permalink | Reply

      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 | Reply

        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 | Reply

      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 | Reply

        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 | Reply

        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

  • Mark Jaquith 4:54 pm on May 18, 2009 Permalink | Reply
    Tags: , , esc_url, esc_url_raw,

    Deprecated clean_url() in favor of esc_url(), and deprecated sanitize_url() in favor of esc_url_raw().

     
  • Mark Jaquith 3:13 pm on May 18, 2009 Permalink | Reply
    Tags: , , esc_attr, esc_html,

    Deprecated wp_specialchars() in favor of esc_html() (also: esc_html__() and esc_html_e()). Using wp_specialchars() with more than one param works for backwards compat. Also, esc_html() (or wp_specialchars() with one param) escapes quotes, just like esc_attr(). This buys security for plugin authors who were mistakenly using a one-param wp_specialchars() call in an HTML attribute. See this wp-hackers message for more detail.

     
  • Peter Westwood 8:20 pm on May 11, 2009 Permalink | Reply

    Trying to keep the commit candidates under control. Every time I look up the list gets bigger.

     
    • Denis de Bernardy 10:45 pm on May 11, 2009 Permalink | Reply

      Yeah, I did some cleaning up and testing. :-)

    • Denis de Bernardy 10:50 pm on May 11, 2009 Permalink | Reply

      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 6:11 am on May 12, 2009 Permalink | Reply

        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 9:16 pm on May 5, 2009 Permalink | Reply
    Tags: , ,

    Standardizing and shortening the WP security escaping functions.

    attribute_escape() is now esc_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 5:04 am on May 6, 2009 Permalink | Reply

      An esc_js() or whatnot might be useful to (i.e. an improved js_escape() (see #7648).

      • Mark Jaquith 5:58 am on May 6, 2009 Permalink | Reply

        Yes, I meant to include that in the list of “coming soon” ones. Though js_escape() would continue to work, as would attribute_escape() and wp_specialchars().

        Improvements to esc_js() née js_escape() are a separate issue — I’ll take a look at that ticket.

    • Leandro Vieira Pinho 3:11 am on May 9, 2009 Permalink | Reply

      Why not escape_attr than esc_attr?. Write escape is more intuitive than esc.

  • Andrew Ozz 12:54 am on May 3, 2009 Permalink | Reply
    Tags: accessibility

    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 8:05 am on May 3, 2009 Permalink | Reply

      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 1:22 pm on May 3, 2009 Permalink | Reply

      Yry NVDA http://www.marcozehe.de/articles/how-to-use-nvda-and-firefox-to-test-your-web-pages-for-accessibility/

      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 10:08 pm on May 3, 2009 Permalink | Reply

      This ticket has some discussion on hidden labels.

    • Lynne 1:30 pm on May 6, 2009 Permalink | Reply

      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 2:40 am on May 8, 2009 Permalink | Reply

        Great point, Lynne! Involve people with disabilities who use various assistive technology in to development and testing.

      • Jane Wells 2:02 am on May 9, 2009 Permalink | Reply

        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 7:07 am on May 18, 2009 Permalink | Reply

        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 2:32 pm on May 6, 2009 Permalink | Reply

      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 3:51 pm on April 25, 2009 Permalink | Reply
    Tags:

    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?

     
  • Widgets redesign 

    Andrew Ozz 4:43 am on April 22, 2009 Permalink | Reply
    Tags:

    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.

     
  • Ryan 3:12 am on April 22, 2009 Permalink | Reply
    Tags: ,

    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 3:09 am on April 22, 2009 Permalink | Reply
    Tags:

    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”.

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
esc
cancel