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?
Updates from April, 2009 Toggle Comment Threads | Keyboard Shortcuts
-
Jane Wells
-
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 Boren
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
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
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
Reviewing GSOC applications
Matt
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
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
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
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
too much work I suppose.
-
Peter Westwood
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
@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
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
I agree
-
Simon Wheatley
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
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
I am kinda liking this idea.
-
Andrew Ozz
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
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.
Jane Wells 5:19 pm on April 25, 2009 Permalink |
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/