wp_register_script() – When to Use

As soon as I had come to know that wp_enqueue_script() function was the proper way of adding script in WordPress, I came to know about one other function wp_register_script(). Having read through some articles I then decided to use wp_register_script() and wp_enqueue_script() simultaneously for each of my scripts. That is I first registered and then enqueued the script. Just like this:

wp_register_script( 'owlcarousel', get_theme_file_uri('/assets/js/owl.carousel.min.js'), array( 'jquery' ), '2.2.0', true ); wp_enqueue_script( 'owlcarousel' ); 

But a few days back I decided to review my research result. That time I got an article (last updated on 8^th November, 2017) from wpbeginner in my hand, which said that –

Now some might wonder why are we going to extra step to register the script first and then enqueuing it? Well, this allows other site owners to deregister your script without modifying the core code of your plugin.

Reference Article:
https://www.wpbeginner.com/wp-tutorials/how-to-properly-add-javascripts-and-styles-in-wordpress/

According to the above article we can register all of our scripts for the prospective developers who might want to deregister those. But I wanted to carry out some further research. Some info could be brought up from the subsequent references -

(wp_enqueue_script()) Registers the script if $src provided (does NOT overwrite), and enqueues it. ¹

In fact, you could just use the ‘enqueue’ function and never use the ‘register’ function. The ‘enqueue’ (wp_enqueue_script())function technically ’registers’ the script. ²

If you try to register or enqueue an already registered handle with different parameters, the new parameters will be ignored. Instead use wp_deregister_script(), and register the script again with the new parameters. ¹

An example of when we would do this i.e., using wp_register_script() instead of wp_enqueue_script(), would be for JavaScript we wanted to add if the page content had a shortcode that needed it. We won't know if a shortcode is in the content of the page/post until long past the wp_head action has run. ²

//if part of theme, in the theme's functions.php 

add_shortcode( 'jht_ideas', 'jht_ideas_app' ); 
add_action( 'wp_enqueue_scripts', 'jht_enqueue_scripts' ); 

function jht_enqueue_scripts() { wp_register_script('jhtscripts', get_bloginfo( 'stylesheet_directory' ) . '/js/dist/app.js', array('jquery'),'1.0.0',true); 
// 'true' here says put script in footer if possible. 
// 'array('jquery')' says this script depends on jquery. 
} 

function jht_ideas_app($atts, $content=null) { 
// do something here... 
wp_enqueue_script('jhtscripts'); 
// tell WP we want the jhtscripts on the page. 
$output = '<div id="jhtMain"></div>'; return $output; 
} 

Reference Articles:

1. https://developer.wordpress.org/reference/functions/wp_enqueue_script/
2. https://jhtechservices.com/wordpress-wp_enqueue_script-vs-wp_register_script/

From the above info it seems that wp_enqueue_script() itself registers the script and the enqueued script can be deregistered and reregistered with new parameters whenever needed. And also, from the code snippet, we learn that we could register our script using wp_register_script only when we don’t want that script to be loaded at once and the script might be loaded later on using wp_enqueue_script(), if needed. In addition to that, I wanted to go over another article for more preciseness. And I found the following:

wp_register_script() registers a script to be enqueued later using the wp_enqueue_script() function.

Scripts that have been pre-registered using wp_register_script() do not need to be manually enqueued using wp_enqueue_script() if they are listed as a dependency of another script that is enqueued. WordPress will automatically include the registered script before it includes the enqueued script that lists the registered script’s handle as a dependency.

Registering scripts is technically not necessary, but highly recommended nonetheless.

If the handle of a registered script is listed in the $deps array of dependencies of another script that is enqueued with wp_enqueue_script(), that script will be automatically loaded prior to loading the enqueued script. This greatly simplifies the process of ensuring that a script has all the dependencies it needs.

So, the main purpose of the register functions is to allow you to simplify your code by removing the need to duplicate code if you enqueue the same script or style in more than one section of code.

Reference article: https://developer.wordpress.org/reference/functions/wp_register_script/ 

Now what? Well, to be much more clear I went over this stackexchange’s post: https://wordpress.stackexchange.com/questions/82490/when-should-i-use-wp-register-script-with-wp-enqueue-script-vs-just-wp-enque 

 Reading so far, I think, your head’s got hot. To be frank, so has mine :P . Joking really.

Now the questions are- 
Should we register a script first and then enqueue it, according to our first mentioned article? And is this a best practice?
Or, should we generally not register each script? 

Well, now that we’ve read through and researched several articles, we can draw a conclusion.

1. Registering any scripts using wp_register_script() is just registering; not loading it. The registered script will not be loaded until it is enqueued using wp_enqueue_script().
2. We don’t need to register and enqueue each of the scripts simultaneously. We should just enqueue. Registering is not mandatory as the wp_enqueue_script() function automatically registers the script.
3. But we do need to register while we are in any of the following situations:
   1. Suppose we need a script to load into more than one place like once in front-end and once in back-end (admin page). Now we can register the script just once. And then enqueue it in front-end and back-end individually. Look, enqueueing means loading. Registering doesn’t mean loading. In case we don’t register it, it will be automatically registered as many times as we enqueue it. On the other hand, if we register it once, it will be registered once, no matter how many times we enqueue it.
   2. If we want to use a script as a dependency of other scripts, then we don’t need to enqueue it with wp_enqueue_script(). Just register it with wp_register_script(). And it will be automatically enqueued when we use it’s handle name as a dependency of other scripts enqueued with wp_enqueue_script().
   3. When we don’t want the script to be loaded at once rather than to be loaded if necessary, we can now just register it for later use. The use case is shown above.

N.B. As far as I am convinced, the same conclusion can be drawn for the CSS stylesheets. I mean to say that we can use wp_register_style() and wp_enqueue_style() in the same way.

Note that the conclusion drawn here reflects my own deduction. If I’m wrong, please correct me. And you might have reached a different and much better conclusion. If thing’s so, then please let us know. Who knows? Perhaps yours is the best. As the saying goes, “As many tenets, as many ways to salvation.” :)

Differences between Git and GitHub

This tutorial is intended for the new and would-be developers/programmers who came up against perception of differences between Git and GitHub.

Note that there might be some informal terms in the article. I’ve purposely used those for the purposes of making things easier to the beginners. I really apologize to the veteran developers and programmers for that.

So, now, let me get into the point.

In a nutshell, there are two noticeable differences between Git and GitHub.

1. Git is a desktop application/software.
2. Github is a website, code repository website. (Almost all the websites out there are web application software though. Just for avoiding confusion I said ‘website’.)

Well, let’s dig in with a bit of perception.
As I mentioned earlier, Git is a desktop software which we need to download from a website(https://git-scm.com/). And then we install it into our local computer as we install other desktop software. Then we need to initiate Git to our project in order to control it (our project) using Git.

To make things simpler, let’s consider that we have a PSD file and we are going to develop a WordPress theme. First we need to convert the PSD to HTML document. And then we need to make the static HTML site dynamic using PHP.

We can assume that there are two steps involved here:

1. PSD to HTML/CSS conversion
2. HTML/CSS to WordPress development.

Now after completing the first stage you may want to keep a copy of the HTML work. You can easily do it by preserving a copy of it on your computer, right? And then keep working on the main project files. But what if you want to preserve the copy of your every single significant change like non-responsive and responsive html designs, with and without carousel versions, with and without JavaScript/jQuery plugin versions, and so on? Now what? Yes, you can also now preserve every copy of them. Even I myself did it previously. But it’s obviously a tiresome and time consuming process. And it’s almost impossible for a big project really. Or, what if you want to get back to your previous code that has already been deleted :( ? This process is called code revision.

Yes, to make keeping code revision easier, Git came to the scinerio. Just download and install Git to your computer, as I mentioned above. Then initiate Git to your project folder. This silly project folder/directory will now be called Git repository, LOCAL repository, as it is located on your local computer. Now your project can be tracked by Git, i.e., you can take snaps of your every single step. And you can get back to any stages of code writing.

Even if you want to keep your several versions of the software, and in case, you want to get back to your previous version, you can obviously do it with Git. That is Git can control your version simultaneously. That’s the reason Git is also called Version Control System (VCS).

Look! All stuff we did so far was on our local computer. We didn’t need online connection, GitHub or anything. We can track our project with Git offline, and no need GitHub.

Let’s assume you have a team of developers. Now you want your project to be done by the team members together. How is it possible? Yes, you’re absolutely right. You need to host the project to such a website the team members can access from their local computer and can work together on it. GitHub is the website that hosts the Git projects. It’s also called the repository of code. According to the OALD, ‘repository’ means a place where something is stored in large quantities i.e., store-house. GitHub is the store house of open source code.
So, now it’s clear that developers/programmers can host their Git projects (controlled by Git software on the local computers) on GitHub (remote computer i.e., website) so that others (developers/programmers/end-users) can contribute to it by developing, and of course, use it individually.

Hope that there’s something worth reading in this article that takes your understanding of the differences between Git and GitHub to the next level.

And it would be appreciated if you draw my attention to any inconsistency, in terms of any info given, English language, or anything. Please let us know your thoughts and experience.

Thanks for taking the time to read.