Matt Mullenweg 4:45 pm on April 1, 2009
Tags: optimization ( 7 )

Idea: We should do a branch prior to rel…

Idea: We should do a branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". prior to release (we do this anyway) and then commit to that branch a minimization of all JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. and CSSCSS Cascading Style Sheets., so trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. always has pretty-formatted, and release branches always have minimized.

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

#optimization

Denis de Bernardy 8:08 pm on April 1, 2009

Isn’t there a way to add an svn hook on tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.)?

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

Its a thought, But many run on trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. 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

Sounds like a must to me.

Also, why not go one step further? Keep trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision.’s PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 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, CSSCSS Cascading Style Sheets., JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors.) 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
  
  too much work I suppose.
- Peter Westwood 6:20 pm on April 7, 2009
  
  Minimising too much in the branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch"./tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) 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
  
  @Peter: obviously, and likewise for CSSCSS Cascading Style Sheets. and JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors., at a lesser level. Hence my suggestion for two archives per tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.): 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

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

1. Less overhead for last minute changes on branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 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 tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.), 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/pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party 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-adminadmin (and super admin).

Just my $0.02
Nate Moore 9:18 am on April 12, 2009

I agree
Simon Wheatley 1:53 pm on April 18, 2009

How about having the JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. 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 SVNSVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase. 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
  
  I believe this is sort of what Andrews code in trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. already does.
  
  Look at the stuff in script-loader.php in wp-includes.
- Shane 12:45 am on April 19, 2009
  
  I am kinda liking this idea.
- Andrew Ozz 1:54 am on April 20, 2009
  
  Peter is right, that’s almost exactly how it works in trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. now. The switch to turn on .dev.js loading is SCRIPT_DEBUG.
Andrew Ozz 1:51 am on April 20, 2009

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 PHPDocPHPDoc (docblock, inline docs)/PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher comments would reduce the download size a lot more.

Comments are closed.

Welcome!

Communication

Idea: We should do a branch prior to rel…

Welcome!

Communication

Share this: