Updates from April, 2009 Toggle Comment Threads | Keyboard Shortcuts

  • 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?

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

    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() {
    	register_widget('WP_Widget_Archives');
    }
    

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

     
  • Ryan Boren 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 Boren 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”.

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

    plugins.php and edit-comments.php remember the last status filter you selected. Try it out. If we like this we can add it to other pages that have filters.

     
  • Peter Westwood 6:21 pm on April 7, 2009 Permalink | Reply
    Tags:   

    Reviewing GSOC applications

     
  • Matt 4:45 pm on April 1, 2009 Permalink | Reply
    Tags:   

    Idea: We should do a branch prior to release (we do this anyway) and then commit to that branch a minimization of all JS and CSS, so trunk always has pretty-formatted, and release branches always have minimized.

    Or this might not be needed with Andrew’s new stuff.

     
    • Denis de Bernardy 8:08 pm on April 1, 2009 Permalink | Reply

      Isn’t there a way to add an svn hook on tag?

      http://svnbook.red-bean.com/en/1.4/svn.reposadmin.create.html#svn.reposadmin.create.hooks

      That way, branches would also be pretty formatted, and only actual released versions would be minified.
      D.

    • DD32 10:04 pm on April 1, 2009 Permalink | Reply

      Its a thought, But many run on trunk daily anyway.

      I cant remember what the constant is to use non-compressed scripts, Maybe if WP_DEBUG is enabled, then non-compressed scripts could be used instantly?

    • Xavier 8:37 am on April 2, 2009 Permalink | Reply

      Sounds like a must to me.

      Also, why not go one step further? Keep trunk’s PHP code clean and commented, and minimize that too in the release branche.
      Of course, that would mean those why want to explorer WP’s inner-working would have to grab the trunk, and that older full-version of WP wouldn’t be fully available.

      So (typing while thinking here), would it be cool to cater to everyone : provide a fully-minimized archive (PHP, CSS, JS) for default users, and keep a “maximized” archive as-well, for further reference?

      (unless, it’s all part of an elaborate April-fools scheme, in which case, well, my case still holds :) )

      • Gmcosta 5:45 pm on April 2, 2009 Permalink | Reply

        too much work I suppose.

      • Peter Westwood 6:20 pm on April 7, 2009 Permalink | Reply

        Minimising too much in the branch/tag will just make patching / generating patches too much work.
        I can see the benefit of js/css minification but not php.

      • Xavier 2:50 pm on April 10, 2009 Permalink | Reply

        @Peter: obviously, and likewise for CSS and JS, at a lesser level. Hence my suggestion for two archives per tag: a fully-minimized as default (for those who won’t look into the code), and an untouched one (for devs and the curious at heart).

        I’m not suggesting minimizing in the branche, since that’s the basis for any further minor version, but for the the tag, which is meant to be definitive – or so I understand.

        I could be way off, obviously. And the profit could me meaningless, but hey, we’re here to discuss :)

    • Robert Accettura 12:59 pm on April 2, 2009 Permalink | Reply

      IMHO this should be part of tagging. There’s a few advantages here:

      1. Less overhead for last minute changes on branch.
      2. Most people who want optimization and polish and can’t do it themselves run tags anyway.
      3. minimized code is harder to debug. If your not using a tag, you should have easy debug abilities.

      Why not just automate the creation of a tag with a make/ant/shell/configure/whatever script that creates minimized versions of js/css (use the format [name].min.[ext]) when a tag is made and changes a flag in wp-config.php to prefer the .min if it exists. This has a few nice things:

      1. Tagging is as simple as running a script which will create the tag, minify, and commit.
      2. No worries about forgetting to update minified and non-minified code like on a branch since tags are (or should be) final.
      3. By using a flag in wp-config.php to prefer minified version of js/css you can just change the flag to use the non-minified versions… This is awesome for when you want to debug.
      4. Theme/plugin authors can utilize the wp-config flag to ensure their theme/plugin offer a minified/non-minified verisons.
      5. As a bonus, you could include the minifier in WP to make it even easier when editing css/js via wp-admin.

      Just my $0.02

    • Nate Moore 9:18 am on April 12, 2009 Permalink | Reply

      I agree

    • Simon Wheatley 1:53 pm on April 18, 2009 Permalink | Reply

      How about having the JS in two states: uncompressed (which the default enqueuing stuff uses if a constant, maybe reuse WPDEBUG?, is specified in wp-config.php) and compressed which is used by default. Uncompressed is used for dev, and an SVN post-commit hook script could automagically compress/minify/pack/whatever’s-currently-best the committed uncompressed JS files. An SVN ignore property could be set to ignore all *.cmp.js files (or some other filenaming schema for compressed files) to ensure they don’t get committed accidentally.

      • Peter Westwood 5:58 pm on April 18, 2009 Permalink | Reply

        I believe this is sort of what Andrews code in trunk already does.

        Look at the stuff in script-loader.php in wp-includes.

      • Shane 12:45 am on April 19, 2009 Permalink | Reply

        I am kinda liking this idea.

      • Andrew Ozz 1:54 am on April 20, 2009 Permalink | Reply

        Peter is right, that’s almost exactly how it works in trunk now. The switch to turn on .dev.js loading is SCRIPT_DEBUG.

    • Andrew Ozz 1:51 am on April 20, 2009 Permalink | Reply

      Currently both the minimized (.js) and the non-minimized (.dev.js) versions of all custom scripts are included. This was mainly so we can test if minimizing works well. If we decide to go with two builds per release: “production” and “development”, we can remove the non-minimized scripts form the first (will have to change script-loader there too). This will reduce the download size/number of files in the install package a little bit, not sure if it’s worth it…

      Stripping all PHPDoc/PHP comments would reduce the download size a lot more.

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
l
go to login
h
show/hide help
shift + esc
cancel
Follow

Get every new post delivered to your Inbox.

Join 906 other followers