There are several fundamental problems with what you’re trying to do that prevent you reaching your goal
The Problems
Naming
You register 2 scripts, but you name them both ‘custom’. How is WordPress supposed to know which script you meant when you later tell it to display ‘custom’?
/* Register scripts. */
wp_register_script( 'custom', JS . '/jquery-3.1.1.js');
// does this overwrite the previous line? ¯\_(ツ)_/¯
wp_register_script( 'custom', JS . '/custom.js');
So lets fix that by giving them different names ( and proper indenting ):
/* Register scripts. */
wp_register_script( 'wpnovice-jquery', JS . '/jquery-3.1.1.js');
wp_register_script( 'wpnovice-custom', JS . '/custom.js');
Notice that I prefixed each, custom
is a super generic term, and it’s possible it’s being used already.
WP Already Comes With JQuery!
Never bundle a library that already comes with WordPress. Doing what you did could lead to multiple copies and versions of jQuery being present on the frontend. Instead, tell WP that jQuery is required for your script:
/* Register scripts. */
wp_register_script( 'wpnovice-custom', JS . '/custom.js', array( 'jquery' ) );
Registration != Enqueing
Registering your script tells WordPress they exist, but not what to do with them. WordPress already registers a lot of scripts, yet these don’t appear on the frontend of every WordPress site.
It’s the difference between teaching somebody how to build a house, and somebody actually building that house.
So, after registering, you need to call wp_enqueue_script
to tell WordPress how to add that script to your page
/* Register scripts. */
wp_register_script( 'wpnovice-custom', JS . '/custom.js', array( 'jquery' ) );
wp_enqueue_script( 'wpnovice-custom' );
Timing
Even with the newest version of that code, it may not work! This is because timing and location are important. In the same way that asking for your steak medium rare after it’s been cooked doesn’t work, asking WP to print scripts when it’s already done the script printing won’t work either.
As a general piece of advice, don’t put code in the global scope sitting in a file, instead wrap it in an action or hook, so that it runs when it’s supposed to ( and can be unhooked when needed ).
Here we want the wp_enqueue_scripts
hook/action. Here’s an example taken from the Core WP docs:
function themeslug_enqueue_script() {
wp_enqueue_script( 'my-js', 'filename.js', false );
}
add_action( 'wp_enqueue_scripts', 'themeslug_enqueue_script' );
A Final Note on Constants
/*-------------------------------------------*/
/* 1. CONSTANTS */
/*-------------------------------------------*/
define( 'THEMEROOT', get_stylesheet_directory_uri() );
define( 'IMAGES', THEMEROOT . '/img' );
define( 'JS', THEMEROOT . '/js' );
I would advise against these, they’re super generic names, and pollute the global namespace. In this case they may be misleading or cause problems.
This version of the register script call, is explicit, and there’s no ambiguity about wether it references the correct URL or not:
// register script
wp_register_script( 'wpnovice-custom', get_stylesheet_directory_uri() . '/js/custom.js', array( 'jquery' ) );