Build tools: We’ve enabled running WordPress from /src again

In May 2018 we’ve introduced a build step to WordPress core development as preparation to WordPress 5.0. While these changes never ended up in 5.0, the idea was to reorganize the way the JavaScript in WordPress is managed and structured so that it would be easier to include Gutenberg.

Since then, it was no longer possible to run WordPress from the src folder. This gave some issues, especially with developing WordPress core PHP. Today, @atimmer committed a patch which allows developers to build into src again.

Developers can now run grunt build --dev to build the JavaScript and CSS into src and use grunt watch --dev to automatically rebuild JavaScript and CSS files when their source is changed.


The biggest advantage of running WordPress from src is that changes in the PHP are immediately reflected on the server again, without an extra build step. If you are only making PHP changes, then you can now build the JS and CSS once using grunt build --dev and continue coding PHP like you were used to.

Backwards compatibility

This change is fully backwards compatible with the previous setup. grunt build without the --dev flag still works exactly the same. No setups based on it should break.

Up next: Use Webpack to build all JavaScript and CSS

There’s an effort going on to move all JavaScript and CSS build logic into the Webpack configuration. Work done on this so far promises to reduce build times significantly. Especially rebuilds triggered by grunt watch should become much faster. Relevant ticket: Use Webpack + NPM scripts to build all the things.

#build-tools, #grunt

Core Build/Test tools chat

I’ll be hosting a chat for Build and Test tools on Wednesday, October 8, 2014 2:00am UTC . The goal will be to triage and discuss the existing tickets along with identifying enhancements, new initiatives, and other improvements.

Please comment below if you have any suggested build/test improvements that are not currently in a ticket.

Note, that this may not be the permanent time for Build/Test tool chats. I know it isn’t ideal for everyone (especially Europe).


Finding and Fixing JavaScript errors with JSHint

The JavaScript Coding Standards have been updated, so it’s time to move on to tackling our JSHint errors!

JSHint is a tool to check for errors in JavaScript code. As was discussed last week, we’re kicking off a small effort to work through our core JavaScript files. To get through the errors revealed by JSHint as quickly as possible, we’re following the model established by the Inline Docs team and posting a list of files with issues so that people can “claim” the files they’d like to fix!

At the bottom is a list of every file in core that is displaying JSHint errors. Files with a checkmark have been patched and should now be passing lint. Files marked with (@username #xxxxx) are already claimed, and being worked on.

Please read and understand the process we’ll be following to address these issues! Many thanks to @azaozz, @nacin and @jorbin for helping identify the safest way to approach fixing these errors, and to @rzen for posting the Inline Docs article on which we based this guide.

How to contribute:

  1. Leave a comment on this post with the file* you’re about to edit (check the list first to make sure it hasn’t already been claimed).
  2. Update your local WordPress SVN to the latest version of WordPress trunk (currently 3.8-alpha).
  3. Create a new ticket on Trac for the file.
    JSHint-related trac ticket settings
    • Format the title as “jshint shouldn’t throw errors – path/to/file.js”.
    • Assign the ticket to the “Build Tools” component.
    • Make sure your email is stored in Trac’s preferences

    If you are logged in, you can click this link to automatically open a ticket with the right settings.

  4. Edit the file, and make a patch. Please make sure you create the patch from the root directory of your WordPress SVN checkout. If you are working on a large file, consider making multiple patches for each type of change.
  5. Upload your patch to the Trac ticket you created, and add the keyword “has-patch”.

*Note: We strongly encourage you to work on one file at a time. These shouldn’t take very long, but if you call a bunch at once and get tied up, we won’t be able to get through these as quickly as possible. To quote @rzen from the inline docs effort, “your edits should be made and patched swiftly so that they aren’t invalidated by (or don’t invalidate) another patch.”

Keeping Discussions Focused:

Any discussion about the specifics of a patch itself should happen on Trac. Discussion about the overall effort should take place during our standing weekly meeting, on Wednesdays at 1900 UTC in #wordpress-dev*.

Files needing patches:

Checked files are now passing JSHint

  • wp-admin/js/common.js (@jorbin, #25912)
  • wp-admin/js/custom-background.js (@jorbin, #25915)
  • wp-admin/js/custom-header.js (@jorbin, #25916)
  • wp-admin/js/customize-controls.js (@jorbin, #25917)
  • wp-admin/js/dashboard.js (@tommcfarlin, #25943) (@nacin)
  • wp-admin/js/edit-comments.js (@adamsilverstein, #25979)
  • wp-admin/js/editor.js (@dougwollison, #25947) (@nacin)
  • wp-admin/js/gallery.js (@dougwollison, #25999) (@jorbin)
  • wp-admin/js/image-edit.js ( #26000)
  • wp-admin/js/inline-edit-post.js ( #26001) (@jorbin)
  • wp-admin/js/inline-edit-tax.js ( #26002) (@jorbin)
  • wp-admin/js/link.js ( #26034)
  • wp-admin/js/media-gallery.js (@tommcfarlin, #25942) (@nacin)
  • wp-admin/js/media-upload.js ( #26023)
  • wp-admin/js/media.js ( #26020)
  • wp-admin/js/nav-menu.js (51 errors)
  • wp-admin/js/password-strength-meter.js ( #25990)
  • wp-admin/js/plugin-install.js ( #25993)
  • wp-admin/js/post.js ( #25994)
  • wp-admin/js/postbox.js (10 errors)
  • wp-admin/js/revisions.js ( #25864)
  • wp-admin/js/set-post-thumbnail.js ( #26008)
  • wp-admin/js/tags.js ( #26009)
  • wp-admin/js/theme-install.js (@kovshenin, #26045) (@nacin)
  • wp-admin/js/theme-preview.js (@tommcfarlin, #25944) (@nacin)
  • wp-admin/js/theme.js (22 errors) (@nacin)
  • wp-admin/js/user-profile.js ( #26016) (@jorbin)
  • wp-admin/js/user-suggest.js ( #26017) (@jorbin)
  • wp-admin/js/word-count.js ( #26018) (@nacin)
  • wp-admin/js/wp-fullscreen.js ( #26029)
  • wp-admin/js/xfn.js ( #25997)
  • wp-content/themes/twentyfourteen/js/functions.js ( #26031) (@jorbin)
  • wp-content/themes/twentyfourteen/js/slider.js ( #26032) (@jorbin)
  • wp-includes/js/admin-bar.js (@kadamwhite, #25970)
  • wp-includes/js/autosave.js ( #26035)
  • wp-includes/js/comment-reply.js ( #26038)
  • wp-includes/js/customize-base.js ( #26039)
  • wp-includes/js/customize-loader.js ( #26040)
  • wp-includes/js/customize-preview.js ( #26019)
  • wp-includes/js/heartbeat.js ( #25986)
  • wp-includes/js/jquery/jquery.table-hotkeys.js ( #26015)
  • wp-includes/js/media-editor.js ( #26022)
  • wp-includes/js/media-models.js (@kadamwhite, #26132)
  • wp-includes/js/media-views.js (@kadamwhite, #25974)
  • wp-includes/js/mediaelement/wp-mediaelement.js (3 errors)
  • wp-includes/js/plupload/handlers.js ( #26041)
  • wp-includes/js/plupload/wp-plupload.js (@atimmer, #26044)
  • wp-includes/js/quicktags.js (@kovshenin, #26046)
  • wp-includes/js/shortcode.js (@tommcfarlin, #25945) (@nacin)
  • wp-includes/js/tinymce/mark_loaded_src.js ( #26014)
  • wp-includes/js/tinymce/plugins/wordpress/editor_plugin_src.js ( #26048)
  • wp-includes/js/tinymce/plugins/wpdialogs/editor_plugin_src.js ( #26048)
  • wp-includes/js/tinymce/plugins/wpeditimage/editor_plugin_src.js ( #26048)
  • wp-includes/js/tinymce/plugins/wpfullscreen/editor_plugin_src.js ( #26048)
  • wp-includes/js/tinymce/plugins/wpgallery/editor_plugin_src.js ( #26048)
  • wp-includes/js/tinymce/plugins/wplink/editor_plugin_src.js ( #26024)
  • wp-includes/js/tinymce/plugins/wpview/editor_plugin_src.js ( #26027)
  • wp-includes/js/utils.js (@adamsilverstein, #25957)
  • wp-includes/js/wp-ajax-response.js (@originalexe, #25954)
  • wp-includes/js/wp-auth-check.js ( #26009)
  • wp-includes/js/wp-list-revisions.js (#25864)
  • wp-includes/js/wp-lists.js ( #26012)
  • wp-includes/js/wp-pointer.js ( #26012)
  • wp-includes/js/wp-util.js ( #25957)
  • wp-includes/js/wplink.js (@jorbin, #25914)

See all open tickets in the Build Tools component

For tips on dealing with global variables, inlined third-party code within first-party scripts, etc, see the JSHint tips in the JavaScript Coding Standards

For the curious, this list was created with a jazzy little command @nacin came up with to pipe Grunt output through ack:

grunt jshint --force | ack '^Linting src/' | ack -o 'wp-.*.js' | sort | uniq -c | sort

What we’re NOT doing

The two JSHint options called out in the earlier post, “curly” and “eqeqeq,” would ordinarily make up the vast majority of the errors JSHint reports in our files. We’ve currently set Grunt and JSHint to ignore these two types of errors when JSHint is run against core. While these are best practices, we’ll come back to them once we address the more significant code smell issues like undefined variables.

Also note that we’re not tackling whitespace or non-JSHint-related refactoring during this effort. We’ll get there, but we have to mitigate the risk to core as much as possible so we don’t interrupt the 3.8 cycle. Keep your changes focused on passing JSHint this go-around.

#build-tools, #javascript, #jshint