The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.?Create a ticket in the bug tracker.
JSHint is a tool to check for errors in JavaScriptJavaScriptJavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. code. As was discussed last week, we’re kicking off a small effort to work through our coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. JavaScript files. To get through the errors revealed by JSHint as quickly as possible, we’re following the model established by the Inline Docsinline docs(phpdoc, docblock, xref) 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:
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).
Update your local WordPress SVN to the latest version of WordPress trunktrunkA 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. (currently 3.8-alpha).
Format the title as “jshint shouldn’t throw errors – path/to/file.js”.
Assign the ticketticketCreated for both bug reports and feature development on the bug tracker. to the “Build Tools” component.
Make sure your email is stored in TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.’s preferences
Edit the file, and make a patchpatchA special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing.. Please make sure you create the patch from the root directory of your WordPress SVNSVNSubversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase. checkout. If you are working on a large file, consider making multiple patches for each type of change.
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-adminadmin(and super admin)/js/common.js (@jorbin, #25912)
wp-admin/js/pluginPluginA 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-install.js ( #25993)
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:
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.
You must be logged in to post a comment.