The Beginner WordPress Developer’s Guide to wp_enqueue

The Beginner WordPress Developer’s Guide to wp_enqueue

While WordPress is powerful, there are plenty of under-the-hood features that can help you maximize its efficiency. In fact, overlooking inherent functions such as wp_enqueue could even impact your site’s overall effectiveness.

If you optimize your themes and plugins correctly, you can improve your site’s performance while enhancing user experience. The wp_enqueue function is a great place to start. This simple integration can prevent issues with your theme when used with other WordPress plugins.

In this article, you’ll learn exactly what wp_enqueue is all about, and how it can be used to improve your WordPress projects. Let’s get started!

Introducing WordPress’ Template Structure

Part of WordPress’ power is its ecosystem of hierarchies and hooks. Hierarchies are driven by a set of special file names, while hooks can be referenced anywhere within a theme or plugin’s structure. Both work together to ultimately create a cohesive front end that is flexible and compatible with an unpredictable combination of themes and plugins.

Let’s start with the WordPress template hierarchy. This has an impact on the way themes are loaded. Whether you are writing a theme or a plugin, it is important to understand how any front-end loading scripts will be incorporated into the hierarchy.

The wphierarchy.com website offers a handy overview of the file hierarchy system.

A primary aspect to understand is that each individual page template gets wrapped around the header.php and footer.php files. With few customized exceptions, both of these files will be loaded no matter what individual page templates get sandwiched between. For example, the home page is loaded like this:

  • header.php
  • home.php
  • footer.php

While an individual post will load these files:

  • header.php
  • single.php
  • footer.php

This way, the top containers with the logo and menu (as well as the bottom containers with any additional footer information) get repeated consistently for every page. This ensures your WordPress page will be correctly, and fully loaded.

Bringing all of this together are WordPress hooks. There are two important functions that get loaded, one into header.php and the other into footer.php. The wp_head() function must be present in header.php:

<?php wp_head(); ?>

While the wp_footer() function must be present in footer.php:

<?php wp_footer(); ?>

They both look for any registered hooks within your plugins and themes. If something needs to be loaded in the header of a page, it gets pulled (or hooked) in by wp_head(), and likewise for the footer by wp_footer().

In other words, you can hook into either of these functions to enable specific unique code to show up on the correct pages of a WordPress website. This is important to understand because WordPress is designed for every single CSS and JavaScript file to be loaded into the theme using these hooks.

While hooks are important for understanding wp_enqueue, they are also the secret ingredient for becoming a power WordPress developer. It’s well worth learning more about how they work and where you can use them.

How wp_enqueue Works

The wp_enqueue() function is a hook in and of itself, which then hooks into wp_head() and wp_footer() as needed. Here’s how it all comes together:

  1. You write a function which registers your scripts using the correct wp_enqueue script.
  2. You hook your function into the wp_enqueue_scripts hook.
  3. These hooks all communicate together so that when wp_head() loads on the front end, your script is found and loaded with the others in the exact correct place.

Neglecting this process means that any theme or plugin that consolidates or reviews scripts will break because yours isn’t loaded using the expected WordPress method. We’ll talk a bit more about that in the next section.

Why Every Single Style and Script Must Be Enqueued

Once you understand how WordPress templates are loaded, you see get why it’s so important you load every single style and script this way. If you don’t, WordPress has no idea your file exists. This is WordPress’ way of keeping track of everything that’s going on within a website.

Consequently, it’s impossible to properly optimize the performance of a WordPress site if even one script is missing. Enqueuing loads your script into the system. This way, WordPress can always replicate it at the correct spot in wp_head or wp_footer regardless of any theme customizations.

Many plugins use the same scripts, but enqueuing enables them to share files rather than attempting to load them multiple times or creating version conflicts. Any optimization plugin or plugins that rely on similar or competing script libraries need to be able to detect these types of issues so they can be debugged and resolved without needing to hack your code. Ultimately, enqueueing scripts ensures greater compatibility across multiple plugins and themes.

How to Use wp_enqueue In Your WordPress Project

Before getting started, it’s important to understand that JavaScript and CSS files load differently. This is because they require different HTML tags. You’ll also want to make backups of your code before making any changes to your site.

If you are working on a live site, you’ll need to access your files using File Transfer Protocol (FTP). FileZilla is a great free cross-platform tool for doing this. Without further ado, let’s jump into coding your scripts into WordPress with wp_enqueue!

Load Scripts Using wp_enqueue_script

Loading JavaScript files is possible with the wp_enqueue_script() function. This function can take five arguments, in this order:

  1. $handle: This is a unique string to name your script, such as my-custom-script, and is required.
  2. $src: This is an optional string pointing to the full path of your desired file.
  3. $deps: An optional array of dependencies. If your script requires jQuery or another registered script, you can list all the handles for those required scripts in an array.
  4. $ver: You can optionally keep track of script versions here using a string for caching purposes.
  5. $in_footer: This is an optional boolean value that forces the script to load in the footer rather than the header.

To register your scripts, you’ll set up a custom function and use wp_enqueue_script to load each one individually. Here’s an example code snippet you can reference in your own theme or plugin.

function torque_enqueue_javascript() { 
    wp_enqueue_script( 'custom-name', get_template_directory_uri() . '/path/to/script.js' ); 
}

Once you’ve created this function, you need to use the wp_enqueue_scripts action hook to actually register it into the system. Below your function, you can use the add_action() function to connect with wp_enqueue_scripts.

add_action( 'wp_enqueue_scripts', 'torque_enqueue_javascript' );

Here, the first parameter is the hook name, and the second is that of your custom function. You’ll want to leave the hook name intact and customize the function name to match yours.

Load Stylesheets Using wp_enqueue_style

Loading in CSS files is incredibly similar, but you’ll use a slightly different function within your script’s loading function. You can choose to keep things separate with an entirely new function to load into wp_enqueue_scripts, or add onto your existing scripts function. For the sake of clarity, we’ll show you how it works in a new function.

The wp_enqueue_style() function also accepts five parameters. Here’s the breakdown:

  1. $handle: This is a unique string to name your CSS file, such as my-custom-styles, and is required.
  2. $src: This is an optional string pointing to the full path of your desired stylesheet.
  3. $deps: An optional array of dependencies. If your script requires another CSS file to work, you can list all the handles for those required stylesheets in an array.
  4. $ver: You can optionally keep track of stylesheet versions here using a string for caching purposes.
  5. $media: This is an optional string to specify media types. You can use media types like all, print and screen. Media queries such as (orientation: portrait) and (max-width: 640px) will also work.

To register your stylesheets, you can either add to the existing custom function or create a new one. We’ll show you in a new function how to use wp_enqueue_style to load each script individually. Here’s the example code snippet for reference:

function torque_enqueue_stylesheets() { 
    // Load main stylesheet 
    wp_enqueue_style( 'my-theme', get_stylesheet_uri() ); 
    // Load other stylesheets 
    wp_enqueue_style( 'custom-name', get_template_directory_uri() . '/path/to/stylesheet.css' ); 
}

With this function ready to go, you can use the same process as before to hook it into wp_enqueue_scripts.

add_action( 'wp_enqueue_scripts', 'torque_enqueue_stylesheets' );

Once again, take note that the hook name stays the same. Only modify the secondary parameter to match your custom function name.

Conclusion

WordPress comes packed with a huge number of developer-friendly features. However, if you don’t learn how to use them effectively, you will wind up with an unwieldy and unreliable WordPress project.

In this article, you’ve learned about how WordPress templates work together and load in scripts from themes and plugins. Because of this ecosystem, it is super important that your scripts and styles are enqueued properly. This can be done using:

  1. wp_enqueue_script: For loading in any JavaScript file necessary for your plugin or theme.
  2. wp_enqueue_style: For registering any CSS files necessary to the front-end design.

What questions do you have about enqueueing files in WordPress? Let us know in the comments section below!

Image Credit: LinkedIn Sales Navigator.

John Hughes

John is a blogging addict, WordPress fanatic, and a staff writer for WordCandy.

The post The Beginner WordPress Developer’s Guide to wp_enqueue appeared first on Torque.

Read Full Article Here

How to Reduce HTTP Requests in WordPress (Make Your Website Faster!)

Learning how to reduce HTTP requests in WordPress sounds like a thing only developers need to deal with. However, in reality it concerns anyone who has a website powered by the CMS.

Here on Torque, we have written extensively on how to speed up your WordPress website:

Reducing HTTP requests is just one piece of that puzzle, yet a very important one. For that reason, this article will deal with how to do so in detail.

In the first part, we will define what exactly HTTP/S requests are and why it’s important to keep their number as low as possible. Then, the rest of the article will show you practical ways to reduce HTTP requests on your own WordPress website.

What are HTTP/S Requests and Why Do They Matter?

Let’s start at the beginning. What is an HTTP/S request?

First of all, whether we are talking about an HTTP or HTTPS request depends on whether you have set up HTTPS encryption on your site. Aside from that, they are the same thing, which is why I will use the two terms interchangeably in this post. However, what are they?

HTTP Requests Happen on Every Website

On the most basic level, an HTTP request happens whenever a browser asks for something from your server. That can be a file like a style sheet, an image, embedded video or script. Basically, everything your site is made up of. Each of these is a separate request.

This is important because only when all requested files have been delivered to the browser does it render your website. Before that, your visitors can’t see it.

As you can guess, the more the browser has to download and process, the longer your site will take to load. That’s especially true if your site is popular. In that case your server has to deal with many simultaneous HTTP requests at once.

That, in turn, has great influence on the user experience, which influences traffic, subscribers, conversions, sales, and more — in short: the success of your website.

They Influence Your Bottom Line

A good example to understand the importance of HTTP requests and its effect on page loading time is Amazon. The company once calculated that a delay of only one second in page load time would result in a loss of $1.6 in revenue per year!

While your site is probably not on the same level of cash flow (however, if it is, kudos!) it will still repel 40 percent of visitors if it takes longer than three seconds to load.

how loading time affects shopping behavior

In addition to that, Google has gone on record that page loading time is a ranking factor. They will also extend this to mobile searches come July 2018. Consequently, any investment into reducing HTTP requests on your WordPress site is an investment into your bottom line.

However, what’s the first step to doing that? Knowing how many requests your site makes in the first place.

How to Check the Number of HTTP Requests of Your WordPress Website?

To reduce the number of HTTP requests on your site, you first have to measure the status quo. Use the following tools to figure out just how big (or small) your problem is.

Chrome Developer Tools

Google’s browser offers in-depth information on how long each site element and file takes to load. Just visit your site and open the browser menu, then go to More Tools > Developer Tools (or hit Ctrl/Cmd+Shift+I).

how to reduce http requests wordpress with the help of chrome developer tools

In the new panel on the side, click on the Network tab.

google chrome developer tools network monitor

Here, you can review what exactly happens on your site and how long each task takes to finish. The browser also offers in-depth information for each element.

Firefox has similar functionality, however, I found Chrome a little more comfortable to use.

Pingdom

Pingdom is my personal favorite when it comes to measuring page speed. The tool has a nice interface and delivers results quickly. Just input your site, select the location to test from and it will go to work.

Besides an overall score, you receive detailed information on areas that could use some improvement.

pingdom test number of http requests
Looks like The New York Times could also use some tips on how to reduce HTTP requests.

It also shows the page weight broken down by content and, most importantly, a waterfall diagram.

pingdom tools waterfall diagram

The latter enables you to track what is loaded when and how long each request takes to complete. Very useful information to take concrete steps to reduce HTTPS requests on your WordPress site.

GTmetrix

GTmetrix is very similar to Pingdom. Through their service, you can learn your overall page speed score and exactly makes your site slow and how to correct it. It also comes with a waterfall diagram.

how to reduce http requests wordpress gtmetrix

Overall, GTmetrix is usually a bit slower and not as nice to look at. However, it’s still very useful and I often use both Pingdom and this tool together.

How to Reduce HTTP Requests in WordPress

Alright, now that you know where the trouble lies, let’s talk about solutions. Below, you find different ways to reduce HTTP requests on your WordPress website. Some of them are a bit technical, however, I have full confidence that you will be able to make them work.

Reduce, Reuse, Recycle

Excessive HTTP requests are most often a thing of having too much stuff on your WordPress site. The most common culprits are plugins. Many of them add their own style sheets and assets to the loading queue of your website.

As a consequence, the first order of the day it to go over your plugin list and boil it down to the bare essentials. De-install what you don’t need, deactivate what you only use occasionally. Be ruthless, your site performance will thank you.

how to reduce http requests in wordpress reduce number of plugins

However, it doesn’t stop at plugins. Next up, get rid of everything else on your site that you don’t need, including themes. Check out our spring-cleaning ebook for more ideas of what you can get rid of. This does not only reduce HTTP requests but also increases security and makes your site more pleasant to work with.

Use the analysis tools above to find files or assets that slow down your site significantly. If that’s the case, find ways to get rid of or replace them.

For everything that stays on your site, you might want to use WP Asset CleanUp. The plugin works similar to lazy loading for images (see below). It detects site assets that don’t appear on pages requested by visitors. If that is the case, it prevents them from being loaded, thus reducing HTTP request.

Delete Unused Images

Among the assets to get rid of, images are of special importance. They not only produce HTTP requests but also usually make up the majority of page weight. For that reason, if you can reduce them, do so!

Like you did with your plugin page, go through the WordPress media library and cut merciless what you are not using. This will also shrink yours in size, which is good news for backups and migration.

Optimize the remaining images that stay for SEO and quick loading. Then further speed up your site via the aforementioned lazy load. Or, if you want to take things to the next level, create image sprites. This combines several images into one and only displays specific portions via CSS.

Concatenate and Minify CSS and JavaScript Files

Talking about combining several files into one, you can do the same with style sheets and scripts. Each of these represents a separate HTTP/S request and thus the less you have of them, the better. One large file usually downloads much faster than several smaller ones.

Plus, you can combine that with minification. This simply means stripping away all characters and formatting that make the files easier to read for human beings. Doing so will greatly reduce the file size and thus speed up their download.

how to reduce http requests wordpress css minification example

You can all of this by hand, for example, with a tool like Gulp. Use this guide to get it right.

However, an easier way is to simply install Autoptimize, which will do all of the above automatically. I have had very good experience with it. Some of the caching plugins below also have that ability.

Be aware, however, that concatenation and minification is no longer necessary with HTTP/2. So, if the majority of your traffic already uses this protocol, this technique will not have as big an effect as it used to.

Limit External Resources

HTTPS requests do not only come from your own site, they can also involve external sources. Popular examples include:

  • Custom fonts — While the services for custom fonts are usually fast, they still produce extra requests. Therefore, here the motto is also: only load what you actually use. This does not only mean limiting the number of fonts but also that of styles and scripts.
  • External images — External images are most common in the comment section, especially since WordPress uses Gravatar by default. You can or switch them off under Settings > Discussion > Avatars or reign them in with these plugins.
  • Social media buttons and counters — Social media is an important marketing tool, however, it’s easy to overdo it. Just like you don’t need to be on every network, you also don’t need to offer sharing options for all of them. Stay with what you are actually using.
  • Embedded videos — Videos from YouTube and other sources are a great addition to your content. If you use a good service, they are also usually served up quickly, however, video embeds are still additional HTTP requests. So, if you don’t need them, get rid of them.

Again, refer to the analysis tools above to find out if any external requests slow down your website excessively.

Use a Caching Plugin and/or CDN

While caching doesn’t reduce the total of HTML request on your site, it can cut down on the number of requests made by repeat visitors. Since it keeps a lot of your site’s content static, people who swing by your site regularly don’t have to download and process everything from the beginning.

The most popular candidates here are WP Super Cache and W3 Total Cache. WP Rocket is a popular commercial solution.

Caching also works well together with a content delivery network (CDN). This means a network of computers distributed across the globe that keep a copy of your site at hand. That way, it can be served to visitors from the nearest possible location.

In addition to that, a CDN offloads HTTP requests to a server other than yours. Splitting the workload that way can greatly enhance your page loading speed.

How Will You Reduce HTTP Requests on Your Site?

Minimizing HTTP/S request in WordPress is a direct investment into user experience and your bottom line. Requests slow down your site, which in turn slows down all other success markers.

In this article, we have defined what HTTP requests are, looked at how to measure them, and gone over ways to have less of them on your WordPress site. In the end, reducing HTTP requests boils down to employing healthy minimalism and only tolerating on your site what you absolutely need.

That doesn’t mean making it boring and unappealing. It just means taking a good look at your web presence and what is essential to it. Cutting out unnecessary components and assets will not only help you reduce HTTP requests and speed up your site but also greatly improve your workflow. That way everybody wins.

What other measures do you know to reduce HTTP requests in WordPress? Anything to add to the above? Let us know in the comments section below!

Nick Schäferhoff is an entrepreneur, online marketer, and professional blogger from Germany. He found WordPress when he needed a website for his first business and instantly fell in love. When not building websites, creating content or helping his clients improve their online business, he can most often be found at the gym, the dojo or traveling the world with his wife. If you want to get in touch with him, you can do so via Twitter or through his website.

The post How to Reduce HTTP Requests in WordPress (Make Your Website Faster!) appeared first on Torque.



Read Full Article Here

How to Create a Full-Featured Security Solution For Your WordPress Website

How to Create a Full-Featured Security Solution For Your WordPress Website

While WordPress itself is inherently secure, its popularity means the platform is a target for hackers. However, it’s often users themselves who become a crucial weak link when it comes to website security. You’ll want to make sure your clients’ sites are locked down, to offer long-term assurance and protection.

Despite the marketing spiels you may find online, there’s no one ‘best’ solution for securing your WordPress website. However, there are a number of plugins and coding techniques that, when combined, provide optimal security against virtually all threats.

In this post, we’ll look at four of those solutions, and explain how they all work together. We’ll also discuss when both the manual and plugin approaches are most suitable. Let’s get started!

Why You Need a Full-Featured Security Solution For WordPress

Ultimately, website security is all about halting malicious attacks, and making sure your users’ personal data can’t be compromised. As you can imagine, there’s a lot that goes into creating a fully secure WordPress website. There are simple concerns, such as having strong usernames and passwords, and more complex considerations (for example, setting up a Secure Sockets Layers (SSL) certificate). In fact, anything that involves user input and data output is potentially an element in need of security.

If you’ve been keeping up to date with the news over the past year or so, you’ll realize that WordPress is a huge target – 70% of WordPress websites are at risk of being breached. Although the platform itself is inherently secure, the mammoth market share it currently enjoys makes it a prime target for hackers. What’s more, WordPress’ modular nature – the fact that it uses themes and plugins – presents risks. This is especially true if those add-ons have been coded poorly.

WordPress carries out stringent checks on each of the themes and plugins submitted to its respective directories, but this doesn’t stop outliers from slipping through the cracks. In fact, WP White Security reports that plugins are the biggest source of vulnerabilities, so having a multi-layered security solution in place is going to be important.

To implement a solid security solution, you’ll need the following two things (at a minimum):

  1. A Web Application Firewall (WAF).
  2. Solutions for stopping malicious access attempts on your site.

There are other recommendations we can make, although they’re secondary considerations. For example, hiding your admin and login page URLs can help in some circumstances. Our advice is to take a look at the relevant Codex article on hardening WordPress (as well as OWASP’s Security Implementation Guidelines) and make whatever additional changes are needed to meet your specific needs.

How to Create a Full-Featured Security Solution For Your WordPress Website (In 4 Steps)

The first line of defense in creating a secure website is having a complete, recent backup. This provides you with a clean slate to work from if the worst happens. Without one, you have no safety net if your site is breached. Once you have a backup solution in place, you can begin to think about your on-site security.

Step 1: Choose a Suitable WAF

A WAF is arguably the most important security aspect to consider, and one that should take precedence above all else. Essentially, a WAF is much like your router firewall. It offers a protective layer between the outside world and your server, restricting access only to ‘good’ traffic and data. For example, many firewalls will block known malicious IP addresses from even knowing that your site (more specifically, your server) exists. Therefore, it’s a vital security component – a virtual deadbolt for your site’s entry points.

In our opinion, a quality host is worth its weight in gold here. Even with that element in place, however, a strong WAF will help your site become practically impenetrable. For many users, Sucuri provides the ultimate in web firewalls:

Sucuri's diagram of how a WAF works.

It’s important to note that this cloud-based WAF operates differently from a quality WordPress plugin solution, such as Wordfence. With Wordfence, there’s an extra layer of processing required in order to stop malicious intent. While that’s usually not a major concern, Sucuri will stop that traffic at its source, without largely impacting your site’s resources.

Even so, both solutions provide a way to protect against direct Denial of Service (DDoS) attacks, zero-day exploits, and much more. For an alternative to these solutions, you could also consider Cloudflare’s WAF:

Cloudflare's WAF page.

Primarily known as a Content Delivery Network (CDN), Cloudflare leverages its expertise by also providing additional security solutions. It’s a strong option for those already using the service who are willing to pay for the upgrade.

Step 2: Protect Against Malicious Login Attempts and Brute Force Attacks

Although a WAF is a good start, it’s unfortunately not going to be enough. We’ve already mentioned the possibility of malicious logins, and it’s worth taking a closer look at what this entails. Ultimately, the entry points to the ‘mother lode’ that is your site are through the login and admin forms. This is for one specific reason – all WordPress sites share similar URLs. While we’ll look at this specific aspect in more detail shortly, let’s look at a potential consequence – brute force attacks.

In a nutshell, there’s nothing stopping a hacker trying to access your site by guessing your credentials. It would take them a while, depending on your password, which from their point of view doesn’t make for an efficient (or income-generating) task. To maximize their efforts, they’ll instead use ‘bots’ to find all of the WordPress websites with a visible login screen, and automatically iterate through passwords at a rapid pace. At some point they’ll achieve success, so without a solution in place, a breach is only a matter of time.

There’s a simple solution here – implement brute force protection on your website. In our opinion, most websites will only need the features found within Jetpack’s many add-ons, more specifically the Protect module:

The Jetpack Protect module.

This is a ‘set and forget’ solution that works in the background to halt brute force attempts in their tracks. However, for more flexibility and customization, Wordfence offers comprehensive protection from this kind of attack, among with many other security features.

Step 3: Obfuscate Your Admin URLs

Our penultimate step is one that’s effective and popular, if not strictly necessary when you have other security solutions in place. Obfuscating (or hiding) your admin and login page URLs builds on the concept of security through obscurity, which has as many detractors as champions. The idea is that, if your URLs are hidden, there’s no way of breaching them.

After all, WordPress’ default admin and login URLs are well-known to everyone with even a passing interest in the platform, including hackers. By automating a bot to search for every wp-login.php URL, they can attempt to brute force millions of sites at once. By changing the URL to something unrecognizable, you give a hacker little chance of ‘smoking you out’. In our opinion, this approach has a lot of merits, but not when implemented as the only method of securing your site. Instead, it should be one segment of a complete full-featured security solution.

If you are looking for a quick and easy plugin solution, WPS Hide Login does the trick, and can be up and running in minutes:

The WPS Hide Login plugin.

However, in our experience there are some disadvantages to WPS Hide Login. For example, we’ve had incompatibility issues with certain caching solutions, meaning that we’ve been locked out of websites, and this solution doesn’t work with VaultPress backups. With that in mind, Elegant Themes recently wrote a piece on manually creating a custom login URL, which is well worth considering if you need another solution.

Step 4: Add an Extra Login Layer to Board Up Entry to Your Website

Our final step is related to the previous one, but is arguably a better solution. Adding a second authentication layer to WordPress’ admin and login pages means that hackers can’t access your username and password fields (which is really the concern). Once a bot is presented with an extra login dialog, it’ll likely move onto the next site. This means you’ll have successfully deflected a brute force attack.

Surprisingly, there are many ways to achieve this. One popular solution is Two-Factor Authentication (2FA). This is a verification step that requires the user to punch in a code from a dedicated app on their smart device. At one point there were many 2FA solutions for WordPress, with varying levels of quality. However, we’re now comfortable recommending two: Keyy, from the developers of the UpdraftPlus backup plugin, and Jetpack’s Secure Sign On module:

A login screen using Jetpack's SSO module.

Both achieve 2FA in different ways. The former uses Google Authenticator to ask you for a code from your smart device, and Jetpack asks you to log in using your WordPress.com credentials. With the latter, there’s also a method to remove your site’s login form entirely, and simply rely on WordPress.com to do the heavy lifting.

Finally, you could also use .htaccess to add a second password layer, which gives you potentially more flexibility to create a custom solution. If you’re not a fan of the current plugin 2FA solutions, password-protecting your URLs in this way could be ideal.

Conclusion

Securing your website is something you should take very seriously. The ramifications of lax efforts on this front can be substantial damage to your site and its reputation. Fortunately, the steps you’ll need to take can be accomplished quickly, even by beginners.

In this post, we’ve discussed how to create a full-featured security solution, incorporating third-party solutions, WordPress’ settings, extra PHP, and a number of WordPress plugins. Let’s recap the four steps you’ll need to take:

  1. Choose a suitable WAF for your site.
  2. Protect against malicious intrusions, including brute force attacks.
  3. Change the login address of your admin and login page URLs.
  4. Add an extra login layer to board up entry to your website.

Do you have any other favorite methods to secure your site, and if so, what are they? Let us know in the comments section below!

Featured image: DariuszSankowski.

John Hughes

John is a blogging addict, WordPress fanatic, and a staff writer for WordCandy.

The post How to Create a Full-Featured Security Solution For Your WordPress Website appeared first on Torque.

Read Full Article Here

An Introduction to Secure Shell Access and Secure File Transfer Protocol

A row of lockers.

Most people use File Transfer Protocol (FTP) to shuttle files and data between their computers and servers. However, although your security provisions may stretch to your live site, the data traveling via FTP will likely remain vulnerable.

To enhance security, it is advisable to use both Secure Shell Access (SSH) and Secure File Transfer Protocol (SFTP) in combination. This way, your data is safe from prying eyes and malicious usage. What’s more, it’s not tough to implement SSH and SFTP into your workflow.

In this post, we’ll introduce both solutions and discuss why they’re necessary. Then we’ll talk about what you’ll need to get started, and explain how to combine the use of SSH and SFTP effectively!

An Introduction to FTP and SFTP

The WP Engine website offers a great infographic on the differences between FTP and SFTP.

First, let’s discuss FTP, which is a common way to access your site’s server. For the uninitiated, FTP enables you to enter a set of connection credentials, which will then let you access the files and folders on your web server. This is done through a dedicated client, meaning you can work within a pleasant Graphical User Interface (GUI) that you’re comfortable with, rather than the command line.

Although FTP isn’t the only way to get under your website’s hood, it’s usually a much quicker method for tackling technical site administration than your WordPress back end. Plus, it’s also quicker for your server to deal with (since you’re directly connecting to it), as compared to the multiple layers involved when logging into WordPress.

For all of these reasons, FTP has become a very popular solution for both beginners and experts to access their servers. However, one big flaw is that the entire process is insecure, and open to malicious intent. In layman’s terms, this is due to the way the data is sent over the network, which uses multiple connections (or ‘channels’). Enter SFTP, which encrypts the connection with SSH using just one channel. As such, while SFTP and SSH are technically separate concepts, they ultimately work in tandem as ‘SFTP’.

How to Implement SSH and SFTP on Your Website (In 3 Steps)

The good news is that implementing a secure method of connecting to your server is a relatively simple process. In fact there are only three steps.

Step 1: Choose a Suitable SFTP/SSH Client and Host

As we’ve discussed, connection between your computer and server requires an intermediary. While you could connect via the command line or terminal, that’s not the most intuitive or easy process for many users. Instead, we recommend a dedicated FTP client. There are plenty of solid options to choose from, although FileZilla is a stand-out choice:

The FileZilla logo.

It’s open-source, free to use, and constantly updated and maintained. What’s more, if you get stuck there are plenty of WordPress-specific guides available to help you. There’s also comprehensive documentation that delves into FileZilla’s functionality further.

Once you have a suitable FTP client, you should also consider whether your host allows an SFTP connection. Most do – for example, WP Engine even has a dedicated knowledge base article on how to connect via SFTP. Ultimately, you’ll need to chat to your host if you can’t find any reference to their SFTP provisions online. They’ll be able to point you in the right direction, which usually includes finding the relevant credentials.

Step 2: Find Your User Credentials

Next up, you’ll want to locate your correct user credentials. Your host should be able to help you with this, although they’re usually delivered via email during your initial signup. It’s important to bear in mind that some hosts will change the name of your server if you upgrade your plan.

How you find your credentials will obviously depend on your web host. If you’re a WP Engine user, you can carry out the following steps:

  1. Navigate to your User Portal, and choose the SFTP users tab.
  2. At the top of the page you’ll see your SFTP address and port number, which you should note down.
  3. If you see a There are no SFTP users for this install notification message on the screen, you’ll need to first create a dedicated user.

For cPanel users, your credentials can be found via User Area > My Accounts > Information & Settings. At this point, you’re ready to connect to your server.

Step 3: Connect to Your Server via SSH

Once you have your credentials and a suitable client in place, the final step is to connect to your server. If you haven’t already done so, making a backup of your website at this point is a solid idea, and can pay dividends if the worst happens while tinkering within your site’s back end.

For WP Engine users, connecting to your server simply requires typing the credentials you jotted down earlier into the relevant fields in FileZilla, which can be found at the top of the client:

The Quickconnect bar in FileZilla.

If all is well, you should be able to connect to your server and browse its content. However, cPanel users have a slightly more convoluted process to work through before being able to connect. The first two steps will take place within cPanel itself:

  1. Generate an SSH key pair from the cPanel > SSH/Shell Access screen, and click on its associated private key link.
  2. Copy the text that appears, and paste it into a plain text document with the .ppk extension.

At this point, open FileZilla, navigate to the Settings menu from the toolbar, and choose the SFTP tab from the left-hand menu:

FileZilla's SFTP settings page.

Next, click Add key file… and select the .ppk file you created earlier. Click Yes at the prompt asking you to convert the file into the correct format, before saving the generated key file on your computer.

At this point, you’ll be able to connect to your server using FileZilla via SFTP, with the credentials you obtained earlier. That’s it – you’ve now established a more secure connection!

Conclusion

While there are multiple ways to secure your website, SFTP is one technique you may have missed. If you’re still connecting to your web server using FTP, you’re putting your site’s data at risk. This connection is a virtual ‘open window’ that should remain locked to the outside world.

This post has tackled the concepts of SFTP and SSH, and outlined why encrypted data is necessary when creating a modern website. We then looked at how to implement SSH and SFTP. Let’s quickly recap the steps:

  1. Choose a suitable SSH client and host.
  2. Find your user credentials.
  3. Connect to your server via SSH.

Do you have any questions about connecting via SSH and SFTP? Ask away in the comments section below!

Featured image: PublicDomainPictures.

John Hughes

John is a blogging addict, WordPress fanatic, and a staff writer for WordCandy.

The post An Introduction to Secure Shell Access and Secure File Transfer Protocol appeared first on Torque.

Read Full Article Here