WordPress.org

Make WordPress Core

Opened 19 months ago

Last modified 3 months ago

#25117 reopened feature request

The distribution build process should be fully available to anyone.

Reported by: mark-k Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Build/Test Tools Keywords: has-patch
Focuses: Cc:

Description

The wordress build environment for each version should be specified in enough detail for third parties to be able to run a build process and get the same distribution as generated by wordress.org.

See discussion about maintaining and documenting the build environment in #24977

Attachments (2)

25117.diff (1.9 KB) - added by nacin 13 months ago.
25117.2.diff (2.6 KB) - added by netweb 6 months ago.

Download all attachments as: .zip

Change History (17)

comment:1 @nacin19 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate of #24976.

comment:2 @SergeyBiryukov19 months ago

  • Summary changed from The distrebution build process should be fully available to anyone. to The distribution build process should be fully available to anyone.

comment:3 @mark-k16 months ago

  • Resolution duplicate deleted
  • Status changed from closed to reopened

Reopening since #24076 was closed without providing the documentation requested here. and now we have the important automatic ltr to rtl conversion getting ready for 3.8.

Without the documentation on setting up the build environment, it will be hard for people to suggest patches for fixing rtl problem as they will have to run the build process to test them.

Yes, me and others can probably figure out what is required, but this info already exists with the core developers and I see no reason to make other people guess what is needed to be done.

comment:4 @SergeyBiryukov16 months ago

  • Milestone set to 3.8

comment:5 @SergeyBiryukov16 months ago

  • Component changed from General to Build Tools

comment:6 @dd3216 months ago

Reopening since #24076 was closed without providing the documentation requested here. and now we have the important automatic ltr to rtl conversion getting ready for 3.8.

To be clear, you want documentation on how to convert the src to build directory via our development tools (Grunt), and not how to build a release package (a zip file) like is distributed on WordPress.org (which is what was originally thought was being asked for by a few people)?

It doesn't look like we have a grunt section in the Core Contribution Handbook yet.

The basic process is, a) Install Node.JS locally b) Install the Grunt package c) Run Grunt's setup process for the WordPress directory, d) Run grunt build in the WordPress directory. I do agree that needs to be documented better though, I'm just including it here as a tip for others searching until proper documentation is written.

comment:7 @kpdesign16 months ago

A new section is going to be added soon to the Core Contributor Handbook that explains the new build environment and how to set it up.

comment:8 @nacin16 months ago

  1. http://nodejs.org/download/
  2. Run this:
    npm install -g grunt-cli
    
  3. In the directory of your SVN checkout of develop.svn.wordpress.org/trunk, run:
    $ npm install
    $ grunt
    

After this, just run grunt. (This is synonymous with grunt build.) You can also run grunt rtl which will generate the uncompressed RTL CSS for you.

npm install only needs to be done once, and then whenever new dependencies are added. grunt commands will fail when it is time to run npm install.

In addition to the handbook, a README file should be added to the root of develop.svn.wordpress.org/trunk.

Or: Check out http://core.svn.wordpress.org/trunk and patch that. If you patch a generated RTL file, someone will help you turn that into a patch for the corresponding LTR file. Honestly, especially for RTL, reporting bugs (and snippets of CSS, if possible) is far more useful than the patch anyway.

comment:9 @mark-k16 months ago

@dd32, sorry I wasn't truly consistent but for me the practical difference is nil. you need to know what tools are used in the build process of the version being developed, and what switches are used to run them if any, and then you just maintain it for the non current versions.

@nacin. so I can't use the tools on ubuntu nor on windows? ;)
Anyway, a blanket statement about installing the latest software from a repository is wrong. Today it will give me version 0.10 and tomorrow it will be 0.11. are there any guaranties that 0.11 will be fully backward compatible to 0.10 and the build script will not break in it?

Or: Check out ​http://core.svn.wordpress.org/trunk and patch that. If you patch a generated RTL file, someone will help you turn that into a patch for the corresponding LTR file

This will create a bottleneck of experts that will have to spend time generating and testing patches that other people could have submitted. This will escalate the more build tools are being used (LESS for example).

About the README - if it can not be indexed by google then it is not useful as no one reads documentation and when people do need documentation they turn to google and not starting to look for readme files.

comment:10 @nacin16 months ago

You can use the tools on any operating system. Node is available for Windows, Linux, Mac, etc. Yes, just install the latest. npm is a package manager that will handle dependencies of the various other pieces of software (grunt, various node libraries, and various grunt libraries).

This will create a bottleneck of experts that will have to spend time generating and testing patches that other people could have submitted.

Maybe. Or maybe those people will continue to submit patches. Any new tooling will *always* increase the barrier to entry somewhat, but the benefits far outweigh the costs. In the case of RTL, this was calculated risk. We have never had a whole lot of RTL tickets open at any given time, and still don't. http://core.trac.wordpress.org/query?component=RTL&status=!closed. But this makes future development easier.

I'm not saying it will only be a readme. I'm saying there will also be a readme.

comment:11 @samuelsidler15 months ago

  • Milestone changed from 3.8 to WordPress.org

@nacin13 months ago

@netweb6 months ago

comment:12 @netweb6 months ago

  • Keywords has-patch added

In 25117.2.diff is the same as 25117.diff with the only change being the inclusion of index.php in each of the /wp-content, /wp-content/plugins and /wp-content/themes folders for the package archives that include /wp-content.

Edit: Patch also includes updates svn:ignore and .gitignore to ignore the /packages folder.
Sidenote: The patch also displays the svn:ignore property change inline with the .gitignore file, a tweak to the Trac configuration should fix this, "whatever" that may be.


I've also pinged @samuelsidler about adding "Build Tools" to the Core Handbook as this is still needed.
http://make.wordpress.org/core/handbook/

I have a good start of this for bbPress already done, copy, paste, and update and we'll get it up soonish.
https://github.com/ntwb/bbPress/blob/master/README.md

Last edited 6 months ago by netweb (previous) (diff)

comment:13 @ircbot5 months ago

This ticket was mentioned in IRC in #wordpress-dev by netweb. View the logs.

comment:14 @jorbin5 months ago

  • Milestone changed from WordPress.org to 4.1

The handbook page is another piece of this, but getting the package task added will help increase our transparency.

comment:15 @ocean903 months ago

  • Milestone changed from 4.1 to Future Release
Note: See TracTickets for help on using tickets.