Make WordPress Core

Updates from Andrew Ozz Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Ozz 5:41 pm on May 25, 2011 Permalink  

    jQuery updates in WordPress 3.2 

    There have been two major releases of the jQuery library during this release cycle. WordPress 3.1 includes jQuery 1.4.4. WordPress 3.2 will include jQuery 1.6.1. The new jQuery is faster and better but also has some major changes. The two most important changes that all plugin and theme authors must test for are:

    • Selectors that include [property=value] now require quotes. So

      will not work. It needs to be

    • All ‘selected’, ‘checked’ and ‘disabled’ properties should use the new .prop() method introduced in jQuery 1.6 instead of .attr(). In most cases .attr() will still work but for example
      .attr('checked', '')

      fails (that used to remove the checked=”checked” from checkboxes). More details and a list of all affected properties are on the jQuery’s blog.

  • Andrew Ozz 7:54 pm on April 27, 2011 Permalink
    Tags: ,   

    Calling all CSS “Gurus”, well everybody that is interested in CSS to voice their opinions about The big CSS overhaul in 3.3.

  • Andrew Ozz 10:35 pm on April 25, 2011 Permalink

    The Distraction Free Writing mode has been in trunk since yesterday. Would appreciate comments, suggestions, opinions, etc. Bug reports should probably go on #17136.

  • Andrew Ozz 8:10 pm on April 4, 2011 Permalink

    To the Directors of White Space 

    Dear Sirs,

    It has come to my attention that our White Space is running wild. Would it be possible to tame that beast back into submission please.

    Seriously, I would like to propose adding another rule to the coding standards: when outputting HTML directly, leave all white space in PHP. Currently we do something like this:

    if ( something ) {
        <div id=...>some more</div>
        <div id=...>even more</div>

    That’s all nicely readable on the PHP side but the outputted HTML is surrounded by quite a bit of redundant space. What I’m proposing is to stop/start PHP immediately around the HTML:

    if ( something ) {
        ?><div id=...>some more</div><?php
        ?><div id=...>even more</div><?php

    This doesn’t impact the readability on the PHP side and produces “tight” HTML with no white spaces as it should be for production. In fact the HTML source would be “pseudo-minified”.

    Of course the readability of the HTML source will be affected but not that much. Currently our HTML output is all over the place which makes it pretty hard to read. Considering that most people never look at the HTML source directly any more thanks to FIrebug and friends and all coding oriented text editors have a function to reformat HTML, I believe outputting “minified” HTML is an advantage. This also reduces the size of our output from 3% to 15% depending on the page.

    Of course I’m not proposing for everybody to rush and reformat the whole codebase if this is accepted. But we can apply it to new code and clean up functions that are being patched for other reasons.

    • Ken 8:20 pm on April 4, 2011 Permalink | Log in to Reply

      This would be fine with me, I also use firebug when examining html.

    • Joseph Scott 8:25 pm on April 4, 2011 Permalink | Log in to Reply

      Wouldn’t it be better to optimize for the code that is read more often (PHP)? For HTML there are plenty of options to minify automatically if you want to go that route.

      • Alex M. 8:44 pm on April 4, 2011 Permalink | Log in to Reply

        This is my thoughts as well. While pretty HTML is nice, pretty PHP should be the priority IMO. Stepping into PHP just to step right back out again on the next line seems like a waste and makes it a lot harder to read.

        As for size, if that’s a concern then gzip should be used.

      • Andrew Ozz 8:55 pm on April 4, 2011 Permalink | Log in to Reply

        Yes, we can minify the HTML automatically but that’s just another (although minimal) overhead. IMHO if we leave all white space in PHP we are optimizing both at the same time.

        Our code is already pretty much optimized for readability on the PHP side. If we accept this as coding standard, it would enhance the PHP side a bit (as we won’t have to think about HTML output formatting at all and can place it anywhere we need) and also enhance the HTML output a lot.

      • Andy Skelton 9:07 pm on April 4, 2011 Permalink | Log in to Reply

        I agree with Joseph. I spend so little time looking at the HTML output that I couldn’t care less what whitespace there is. When I’m looking at PHP, I don’t want to have to look at the beginning and end of every line. That’s even worse than reading a long column of echoes.

      • Andrew Nacin 11:17 pm on April 4, 2011 Permalink | Log in to Reply

        I agree with Joseph and Andy as well.

      • Brian Layman 2:28 pm on April 6, 2011 Permalink | Log in to Reply

        I’m in this camp too.

        Plus this may appear moderately readable with two lines but once you get into more it doesn’t hold up nearly as well. I’d rather be consistent in our handling and also save 7 bytes per line of code.

    • Jon Brown 8:36 pm on April 4, 2011 Permalink | Log in to Reply

      Isn’t what you’re proposing the opposite of the existing coding standards which are to open/close php around the actual PHP? More like:

      if ( something ) { ?&gt;
           &lt;div id=...&gt;some more&lt;/div&gt;
           &lt;div id=...&gt;even more&lt;/div&gt;
      &lt;?php }

      Which is compact and doesn’t needlessly open and close php (although I’m pretty sure that’s been shown not to be a performance issue, right?)

      • Ramoonus 12:33 pm on April 5, 2011 Permalink | Log in to Reply

        this is what I prefer, much easier to read
        and most programs can do color coding with this format

    • Mike Schinkel 8:50 pm on April 4, 2011 Permalink | Log in to Reply

      Here’s a question I don’t know the answer to: Is there any performance penalty for excessive context switches between PHP and HTML? Also, rather than context switching, why not use HEREDOCs instead?

      • Andrew Ozz 8:59 pm on April 4, 2011 Permalink | Log in to Reply

        As far as I can tell, no. No performance penalty for switching in and out of PHP at all. IMHO HEREDOC is quite hard to read and is inflexible in many cases.

    • scribu 9:06 pm on April 4, 2011 Permalink | Log in to Reply

      We should avoid context switches, not for site performance, but for developer performance, as Joseph Scott already mentioned.

      Adding more characters to reduce whitespace doesn’t seem like a sweet deal to me. A standard in this area would be good, but not that one.

      How about:

      if ( something ) {
          &lt;div id=...&gt;
          &lt;div id=...&gt;&lt;?php inline_call(); ?&gt;&lt;/div&gt;

      Multi-line blocks should never be indented.

      • Alex M. 9:09 pm on April 4, 2011 Permalink | Log in to Reply

        This is how I write and prefer code.

      • Andy Skelton 9:12 pm on April 4, 2011 Permalink | Log in to Reply

        I recently banished all thoughts of pretty HTML and decided to focus on PHP indentation. So I indent the PHP tags. Here’s my example:

        if ( $lines ) {
            &lt;div id=&quot;lines&quot;&gt;
            foreach ( $lines as $line ) {
                &lt;p class=&quot;line&quot;&gt;&lt;/p&gt;
    • Ken 9:09 pm on April 4, 2011 Permalink | Log in to Reply

      Alternatively, we can recommend NOT using indents for html blocks, but rather line-breaks and comments:

                  if ( something ) { ?&gt;
      &lt;!-- #someid --&gt;
      &lt;div id=&quot;someid&quot;&gt;some more&lt;/div&gt;
      &lt;div id=...&gt;even more&lt;/div&gt;
      &lt;!-- /#someid --&gt;
                  php }

      I’d just be happy with any standard.

      • Brian Layman 2:30 pm on April 6, 2011 Permalink | Log in to Reply

        I imagine my preferred standard of making the HTML indented to the correct level when the HTML source is viewed would be generally hated by all :)

    • miqrogroove 9:24 pm on April 4, 2011 Permalink | Log in to Reply

      The only time this white space has ever mattered to me is when dealing with textarea elements, which have a required trailing linefeed. At any other time, I would prefer the former syntax for simplicity and let the HTML look slightly out of alignment. I would never try to minify my HTML.

      • Ken 9:30 pm on April 4, 2011 Permalink | Log in to Reply

        There was a trac ticket a while back about white space between Nav LIs that caused styling issues… He was setting the menu items to display: inline. That and your textareas are the only things I can think of.

    • demetris 10:12 pm on April 4, 2011 Permalink | Log in to Reply

      I think the gain in size is not worth it because, when the document is gzipped, the reduction in percentage is much smaller: 2 or 3 percent at most. (Which, in absolute numbers, is an even smaller gain.)

      My personal preference at present is to always stay in PHP mode. I use echoes with a line feed at the end of the string. So, the only white space in the generated HTML is line feeds. (One reason I started using this style is that HTML highlighting with a PHP document distracts me.)

      • Andrew Ozz 10:33 pm on April 4, 2011 Permalink | Log in to Reply

        Agreed. Assuming that most hosting companies gzip HTML by default the gain will be even smaller: about 0.1% and under as white space compresses extremely well.

      • Jan Fabry 6:47 am on April 5, 2011 Permalink | Log in to Reply

        Indeed, I also prefer to stay in PHP mode. With this proposal the difference will be even smaller, so if there would be a change, I propose it is to PHP-with-echo everywhere.

    • arena 10:59 pm on April 4, 2011 Permalink | Log in to Reply

      ok for me and please please remove the trailing and useless ?> in most wordpress php files

      • Peter Westwood 7:15 am on April 5, 2011 Permalink | Log in to Reply

        It’s not useless – it is good practice in my opinion and makes it easier to identify when people have uploaded part of a file by FTP

        • Mike Schinkel 7:21 am on April 5, 2011 Permalink | Log in to Reply

          I’ve seen whitespace after a trailing ?> cause syntax errors. I’ve never seen those same syntax errors occur when there is not a trailing ?>. FWIW.

        • Peter Westwood 7:24 am on April 5, 2011 Permalink | Log in to Reply

          Syntax errors seems unlikely, Headers already sent is probably what you saw.

        • Mike Schinkel 7:28 am on April 5, 2011 Permalink | Log in to Reply

          Possibly. Either way it was a fiddly error that can take a while for many people to track down. Again, FWIW.

        • Dion Hulse (dd32) 8:50 am on April 5, 2011 Permalink | Log in to Reply

          Mike: Thats the exact reason why user editable files in WordPress don’t have the closing php marker (wp-config-sample.php and themes functions.php)

          But for all other files, no user should edit them, so its a useless argument there

        • Mike Schinkel 8:57 am on April 5, 2011 Permalink | Log in to Reply

          @dd32 – Although it’s not worth debating as an attempt to change the opinions of the core team related to the source files in WordPress, as a point of note it is not completely useless.

          People accidentally modify files all the time. If they open a core file to learn what it does but accidentally add white space to the end they can spend quite a bit of time trying to figure out why their site code now fails although they can’t “see” any difference.

          Again, FWIW.

    • arena 11:28 am on April 5, 2011 Permalink | Log in to Reply

      having or not having a ?> at the end of a file do not mean you have reached the end of the file ….
      then change the
      trailing ?>
      /* end of file */

    • John James Jacoby 1:22 am on April 12, 2011 Permalink | Log in to Reply

      I’m against the grain with everyone here. Go figure. :)

      I think having pretty HTML output is important, because scanning through randomly indented HTML output is as irritating as scanning through randomly indented PHP. Call me old school, but I miss the days of having poetically formatted HTML when viewing HTML source on a site. :)

      I also prefer not to echo out HTML from inside PHP, and rather close out of PHP and output raw HTML. PHP is a scripting language that essentially provides logic to HTML. Using it to output complete lines or blocks of HTML seems counter-intuitive to me, so it’s reserved in my toolbox for special cases where I may want to filter that chunk of HTML through a WordPress filter.

      This was one of my original kvetches about WordPress when I stopped lurking and started posting in the support forums. (Embarrassing reading my tone back then as an outsider to the community.)

      The problem arrises from having tabs in front of the PHP open brace. It’s good for PHP code readability, but bad for HTML output readability.

      This example taken from index.php of twentyten:

      &lt;?php get_header(); ?&gt;
      		&lt;div id=&quot;container&quot;&gt;
      			&lt;div id=&quot;content&quot; role=&quot;main&quot;&gt;
      			/* Run the loop to output the posts.
      			 * If you want to overload this in a child theme then include a file
      			 * called loop-index.php and that will be used instead.
      			 get_template_part( 'loop', 'index' );
      			&lt;/div&gt;&lt;!-- #content --&gt;
      		&lt;/div&gt;&lt;!-- #container --&gt;
      &lt;?php get_sidebar(); ?&gt;
      &lt;?php get_footer(); ?&gt;

      …should really be…

      &lt;?php get_header(); ?&gt;
      		&lt;div id=&quot;container&quot;&gt;
      			&lt;div id=&quot;content&quot; role=&quot;main&quot;&gt;
      			/* Run the loop to output the posts.
      			 * If you want to overload this in a child theme then include a file
      			 * called loop-index.php and that will be used instead.
      			get_template_part( 'loop', 'index' );
      			&lt;/div&gt;&lt;!-- #content --&gt;
      		&lt;/div&gt;&lt;!-- #container --&gt;
      &lt;?php get_sidebar(); ?&gt;
      &lt;?php get_footer(); ?&gt;

      The differences being the whitespace before the opening and closing PHP braces is gone, and there is an additional empty line before and after the context switch to ensure the output of get_template_part() has breathing room. In the above example, the next problem is that loop.php starts out only indented 1 tab in, rather than 4, which starts the cycle of messy HTML whitespace over again.

    • John James Jacoby 1:35 am on April 12, 2011 Permalink | Log in to Reply

      Maybe we should write a plugin to format the HTML output for us?


  • Andrew Ozz 9:14 pm on December 3, 2009 Permalink  

    WordPress Developer News: WordPress 2.9 Beta 2 

    WordPress 2.9 is currently in beta and is expected to be ready in several weeks.

    Major new features for developers:

    • comments meta table
    • improved support for custom post types
    • register_theme_directory() for additional theme locations
    • back-ported JSON encode/decode for both PHP and JavaScript

    and for users:

    • oEmbed support
    • “Trash” for posts, pages and comments
    • post thumbnails support
    • basic image editor

    More details are available in the Codex https://codex.wordpress.org/Version_2.9 and on trac.

    New feature in the plugin repository: logged in users can enter compatibility information about all plugins – works / doesn’t work for several recent versions of WordPress. It is still in beta and in data collection mode. When it’s released, the collected information will be available from the wordpress.org API.

    As with every release there are hundreds of improvements and bug fixes. 410 tickets have been closed so far for the 2.9 milestone.

    One significant change is the new “trash” status for posts and comments. It works by changing the post_status or the comment_approved field to ‘trash’. If the post or the comment is restored from the trash that field is set back to it’s previous value. By default items in the trash are deleted after 30 days.

    If you use direct SQL queries you may need to exclude posts and comments that are currently in the trash. Simple example: https://core.trac.wordpress.org/changeset/12254

    Please ensure that your plugin(s) or theme(s) work as expected in WordPress 2.9-beta-2. If you have questions or comments please post them on the wp-hackers mailing list or in the Alpha/Beta forum on wordpress.org.

  • Andrew Ozz 8:51 pm on December 3, 2009 Permalink  

    Agenda for the December 3rd Dev Chat 

    • How do we handle security releases in the admin – Matt Martz
    • Create a post on the wp.org dev feed that highlights what breaks to plugin devs – Denis de Bernardy (we’ve started the WordPress Developer News email announcements as discussed here couple of months ago that cover this)
    • Shall we remove Gears support now or in 3.0
    • Minimum intervals between first beta and final release and between first RC and final – demetris
  • Andrew Ozz 3:59 am on September 26, 2009 Permalink

    Image Editor 

    The “first run” of a simple image editor has been in WordPress 2.9-rare for about two weeks. It lets the user crop, flip and rotate an image. It also has an option to scale the original (largest) image and to restore the originally uploaded version. There is a multi-step undo and redo support. Changes can be applied to all image sizes or only the thumbnail. The initial code is by Stephan Reiter author of the Scissors plugin.

    Currently when saving an edited image all previous intermediate image sizes are kept and the meta data for them (filename, width, height) is moved to another postmeta field. This is necessary to avoid breaking any posts or pages where the image was inserted. The editing workflow (multi-undo, preview of each step) makes it unnecessary to edit an image more than once or twice, however if an image is edited 6-7 times the backup files would be 25-30.

    There are couple of ways to avoid keeping unnecessary images, we could either track when an image was used in a post or a page, or we could have “standard” names for the intermediate image sizes. Tracking image use can be somehow problematic considering all the different ways content can be published in WordPress.

    Renaming the resized images from [imagename]-150×100 to [imagename]-thumbnail, etc. seems the more viable option. This would also bring instant image updates in already published posts, however may also have some compatibility problems with plugins that expect the image size to be part of the filename.

    Trac ticket for the image editor, suggestions and patches welcome :)

    • Alex (Viper007Bond) 5:02 am on September 26, 2009 Permalink | Log in to Reply

      You could also just use a shortcode for the image tag, although that may not be as user friendly. Then again, if you move domains, URLs, etc. you wouldn’t have to edit the post.

      So instead of this:

      &lt;img src=&quot;http://blog.com/wp-content/uploads/imagename-thumbnail.jpg&quot; width=&quot;150&quot; height=&quot;100&quot; title=&quot;Cool image&quot; alt=&quot;ohai&quot; /&gt;

      You’d do this:

      [image id=&quot;123&quot; size=&quot;thumbnail&quot; title=&quot;Cool image&quot; alt=&quot;ohai&quot;]

      The URL, width, and height would all be dynamic and change if you changed the thumbnail size, etc. This is opposite of now where even if the filename didn’t contain the dimensions, you’re still left with hard coded width/height parameters in the image tag.

      • scribu 11:49 am on September 26, 2009 Permalink | Log in to Reply

        That would be nice. And it’s been requested several times in the past.

      • Xavier 4:47 pm on September 26, 2009 Permalink | Log in to Reply

        • Beau 9:30 pm on September 26, 2009 Permalink | Log in to Reply

          Since both uploads would have a unique id in the DB, it doesn’t matter if they have the same filename. The correct URL would be output dynamically, based on wherever it was stored (as referenced by the DB)

      • Andrew Ozz 12:57 am on September 28, 2009 Permalink | Log in to Reply

        Think this came up when we were doing the captions shortcodes a year ago and was rejected. Perhaps we can look at the pro & con again. Since all movies and other embeds will be handled by shortcodes it may make sense to extend that to include images too.

        However I see a possible problem with that. The img tag doesn’t need any processing on display but a shortcode would need quite a lot as it seems we will have to do get_post() for the attachment. Also our shortcode parsing code/API doesn’t seem optimized enough to handle large quantity of shortcodes.

        • aarondcampbell 8:20 pm on October 3, 2009 Permalink | Log in to Reply

          It is true that it can’t handle really large posts with lots of shortcodes. However, that’s definitely only affecting a very small percentage of people (if we’re really focusing on the 80-20 principle, it’s less than 20%). Do we really think that enough people will be writing stuff this long (and putting enough shortcodes in it) that we should worry about it? (That’s the post where I first ran into the issue…I tried to explain that it was just too long, but apparently it’s quite effective as it is).

          I like the shortcode idea.

        • Andrew Ozz 2:31 am on October 5, 2009 Permalink | Log in to Reply

          True, this is very rare at the moment but turning img tags into shortcodes would increase that number, perhaps a lot.

          No, don’t think we can apply the 80/20 principle here. Would that mean we can break up to 20% of all published posts? :)

          The problem is that even a shorter post with a lot of images will reach the backtrack limit or be very slow to display.

        • DD32 2:58 am on October 5, 2009 Permalink | Log in to Reply

          > or be very slow to display.

          Reminds me of the mention of storing filtered post contents along side the raw and serving those up instead of applying the expensive filters every load..

        • Andrew Ozz 3:19 am on October 5, 2009 Permalink | Log in to Reply

          Yes, post_content_filtered is still in the posts table. Think there are few plugins that do this, not sure how well though as it bypasses all ‘post_content’ filters.

        • Alex (Viper007Bond) 3:38 am on October 5, 2009 Permalink | Log in to Reply

          Perhaps storing a partially cached version would be best, i.e. just internal shortcodes. You’d break a lot of plugins if you rendered the entire content from a cached copy.

      • Jonathan Dingman 9:22 pm on October 1, 2009 Permalink | Log in to Reply

        Would that imply dynamic resizing?

        ie, if someone changed the thumbnail size after already uploading the image, would it resize on the fly? (if specifying a thumbnail in the shortcode)

      • Denis de Bernardy 11:14 pm on October 3, 2009 Permalink | Log in to Reply

        Using a shortcode here would hammer the DB unless it’s properly implemented.

        And this “it hammers the database”, btw, is the reason I had opened:


        I use similar code in two plugins of mine, and since you can’t rely on an attachment from being tied to a single post, I check for a post meta to make sure there are attachments (and which ones) before tossing a query.

      • Alex (Viper007Bond) 6:56 am on October 4, 2009 Permalink | Log in to Reply

        We also have to not forget about those who use TinyMCE and expect to see the image as is. A shortcode would be there as text.

        Perhaps a TinyMCE plugin could AJAX fetch the image (based on ID) and replace the shortcode with the image during editing, then put it back to the shortcode on save. That way it’d still stay a WYSIWYG.

        • aarondcampbell 9:53 pm on October 4, 2009 Permalink | Log in to Reply

          That’s a good point. It’s easy to forget about those using WYSIWYG

    • Barış Ünver 6:33 am on September 26, 2009 Permalink | Log in to Reply

      I’m concerned about the fact that WordPress is getting fatter and fatter each version. Is it really necessary? Couldn’t it be done with a plugin or something?

      Or at least, are we gonna be able to se a lighter (official) version of WordPress? LitePress v2.9.0 maybe?

      • Alex (Viper007Bond) 9:14 pm on September 30, 2009 Permalink | Log in to Reply

        Filesize (aka fat) is not directly related to performance. The image editor for example has literally zero (no joke on the literally) impact on the front page of your site for example as it’s never loaded except in the admin area.

        • Andrew Ozz 12:15 am on October 1, 2009 Permalink | Log in to Reply

          On top of that even in the admin it’s only loaded through AJAX so it doesn’t add any overhead anywhere.

      • aarondcampbell 8:22 pm on October 3, 2009 Permalink | Log in to Reply

        It’s all about the 80-20 rule. I think more than 80% of the people will use this on a regular basis. I probably won’t, but most of my clients will. I’m all for keeping code as lean as possible, but I’m also all for adding this support in. Let’s trim in other areas. Just my 2 cents.

    • Andrew Ozz 1:37 am on September 28, 2009 Permalink | Log in to Reply

      Another solution for the multiple image backup files would be to let the user decide. We can include a checkbox whether to delete the previously edited image (together with all sub-sizes). Since the suffix that is appended to the image filename contains a timestamp, we could do something like “This image was last edited 1 hour ago. If it wasn’t used in a Post since then you can remove the backup files by selecting this checkbox”.

      On the other hand even the cheapest hosting accounts seem to come with a lot of storage so deleting backups would be unnecessary. Also a plugin can add a simple GUI to search the db and return a list of unused backup images that can be deleted. Not sure if something like this would be good for core.

    • Otto 6:07 pm on September 28, 2009 Permalink | Log in to Reply

      I think the key to this problem is the following: “This is necessary to avoid breaking any posts or pages where the image was inserted.”

      Why avoid breaking those posts/pages? If somebody edits an image, then change the image itself. That’s what they will probably expect to happen.

      Having to have them go and reinsert the changed image into the page/post is confusing and unnecessary. We don’t need to save the original. The user uploaded the image, presumably they have the original. An in-place editor should simply overwrite the existing files with the new ones, not try to preserve them.

      • Andrew Ozz 12:30 am on October 1, 2009 Permalink | Log in to Reply

        True, users that know what they’re doing may expect to break old posts when editing an image. However the majority will most likely complain that “the image editor breaks all old posts!”.

        Also we cannot just replace the originally used image with the edited one as images are inserted with “width” and “height” attribs that in most cases will distort the edited image (as Viper007Bond pointed above).

  • Andrew Ozz 12:54 am on May 3, 2009 Permalink

    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 | Log in to 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 | Log in to 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 | Log in to Reply

      This ticket has some discussion on hidden labels.

    • Lynne 1:30 pm on May 6, 2009 Permalink | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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 | Log in to 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.

  • Andrew Ozz 4:43 am on April 22, 2009 Permalink

    Widgets redesign 

    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() {

    For more details and examples check wp-includes/widgets.php and wp-includes/default-widgets.php.

  • Andrew Ozz 4:41 pm on February 6, 2009 Permalink

    Script loader updates 

    There are several updates to the script loader currently in WordPress 2.8-bleeding-edge that enhance and optimize loading of external JavaScript and CSS files.

    Probably the most important change is that scripts can be queued for loading in the footer for both the admin and the front-end. This is done with an optional argument. To enqueue a script for the footer:

    wp_enqueue_script( 'name', 'url/to/file.js', array('dependency'), 'version', true );

    where “true” means enqueue for the footer (“false” is the default and is optional).

    When a script is enqueued for the footer all dependencies will be added (if not already present) and will be printed before the script. Some may be in the head, others also in the footer. By default only jQuery is printed in the head but when a script is enqueued for the head, all dependencies would also be printed in the head. Almost all external scripts would run onload or after the page has loaded, so there’s no real need to queue anything for the head.

    Scripts queued for the front-end footer depend on wp_footer(); being present in the current theme. Unfortunately some themes don’t include it. The best way to remedy this would be to bring awareness among users and theme designers as suggested by several plugin developers.

    To make queueing of scripts easier two new actions have been added: "wp_enqueue_scripts" that runs in the front-end head where all is_page(), is_home(), etc. functions are available and "admin_enqueue_scripts" that runs in the admin head and has the current page hook as argument, so scripts can be queued only for specific pages.

    Another major new feature is that all core admin scripts are concatenated and compressed before sending them to the browser. This feature can easily be extended to include scripts added by plugins and to use server side caching, however that would require some changes to the server settings (.htaccess on Apache).

    Since compression from php can be problematic on some hosts there are several “switches” (constants) that manage it: define('CONCATENATE_SCRIPTS', false); would turn off both concatenating and compressing of all scripts. It’s intended for script debugging, define('COMPRESS_SCRIPTS', false); can be used to turn off compression for JavaScript and define('COMPRESS_CSS', false); for CSS files. Compression is set to “deflate” by default since it’s faster and uses a little less server resources. Gzip can be forced by setting define('ENFORCE_GZIP', true);

    There is a test if compressing from php works as expected on the server and whether the server compresses scripts by default. It runs only once and saves the result in an option “can_compress_scripts”. It would run again if the option is deleted.

    In addition all core scripts are minified. All custom scripts are included in two versions: .dev.js is the non-minified script and .js is the minified one. The constant define('SCRIPT_DEBUG', true); would load the .dev.js versions of the scripts making them easier to debug.

    Possible changes: removing the COMPRESS_CSS switch and using only COMPRESS_SCRIPTS, using deflate for compression but adding the gzip file header and serving it as “Content-Encoding gzip” since it seems more compatible with the various web servers and proxyes (all modern browsers support deflate well).

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar