Back to Education Center Home: Want darker text? Sounds pretty obvious spelled out like that, right? It's right there in the name So, now you're wondering what a server-side language is, and whether or not you're using one. Well, if you're building a web site that uses even the simplest of databases, then you're using a server-side language. It's just code that's processed on the server before being sent to website visitors.
There are all sorts of languages out there. So I'm not going to go into which server-side language is best for you, which one you should use, or even how to pick the best one in this article. I will tell you that they all require a server to run.
So regardless of your experience and expertise at any or all of the server-side languages, you cannot preview that site you're working on until it is living in a server environment. There are two server environments to choose from: A local server is, as you might have guessed, hosted locally on your own computer while a remote server is hosted elsewhere.
It might be a paid hosting plan, another computer on a local area network, or even a free hosting plan; regardless, a remote server is a server that is not on your computer. So, which type is best for testing?
That's really up to you. I prefer the local server route, and that's what I am going to focus on today. But I often encourage my clients to also set up remote testing servers, which I will also cover today. And quite often these mistakes can't be found until you see the site running. And since a server is needed to execute the dynamic, server-side code and turn it into HTML, this means you absolutely need a test server to preview and test the various aspects of your site.
I Know What I'm Doing Eeek, I cringe at the thought. Technically speaking, yes you can absolutely test everything you want using the web site itself. But it's not recommended no matter how experienced you are.
Anything can go wrong. A simple mispelling can result in the site getting locked down, forcing you or someone else to scramble to regain access and undo what you did. Security holes may appear while you're testing.
And even if the worst case scenarios don't happen Depending on the client, if he or she decides to check out the site and sees a mess, he could very well start losing faith or enter into a panic. Neither of which offer very good outcomes. And finally, if it's a site that has already been launched, then it just doesn't make sense to do any more testing on it.
Sure, while the site is brand new and not yet available to the public, testing on the site itself has fewer risks. But testing on a site that is already established can lead to embarrassment, excessive downtime and even security breaches. No, no Even if you are the absolute most experienced developer in all the land — I still wouldn't recommend testing anything directly on the web site. It's much better to do the majority of your testing on a local server that only you can access, some pre-launch testing on a remote server that you and your client can run through, and leave your live site a test-free zone.
Almost anything. If it is or will be going on a live web site, then it can be accomplished on your local test server. Whether you're testing out layouts, shopping carts, auction scripts, memberships, or even directories — it can always be set up on your local server. Whether you're testing for workflow or compatibility, installing everything onto your local server is generally a good first step in the debugging process. And don't forget all the new toys D I can't count how many hours I have wasted just playing with new toys on my local server with no particular client in mind.
I see a new module come out for Drupal — I get it installed and start playing almost immediately. It's for this very reason that I constantly keep a new installation of Drupal running on my local test server. By running a local test server, you give yourself the opportunity to build upon your already strong skill set, expanding to new territories and making yourself an even stronger developer. You can also work virtually uninterrupted from network failures, Internet outages or other headaches that might keep you from uploading everything onto a remote server.
And by having a local test server, you won't have to waste any time uploading, testing, fixing, reuploading, retesting, etc. Installing your favorite CMS onto your local test server requires only that you extract the files into the correct folder. And most of your favorite browser extensions will still work while you're viewing your site from your local test server as well.
These all still work very well to help you check things out on the site while it's still on your local test server. Things like analytics and load times won't be accurate until you're accessing the site from a remote location.
This is especially true of load times — since loading a web site from your local computer is always faster than loading the same web site through a network. And best of all, you can do all these things without affecting the integrity or security of a live site.
Even some of the most tested and widely used systems in the world can have security holes in them. Sites built on WordPress or Drupal, for example, are constantly being modified and improved upon to avoid and address these weaknesses in security — ones that exist despite their popularity and widespread use. When working on a new plugin or module or sometimes even just a new feature with either of these two content management systems, security can be threatened — even if only for a few minutes.
And I don't think I need to tell you what can happen to a web site that loses its top notch security for a few minutes. What Is a Test Server?
Years and years ago, when Perl was still very, very new, I didn't know very many people who had test servers. In fact, I think that out of the hundred or so web developers that I knew, only two or three of them actually had a test server.
This is an abysmally low ratio compared to today. You see, back then, test servers were something of a luxury. Large web development companies and corporations had walls of servers available for, well, anything really. They used them for testing, staging, hosting — you name it.
Individual or freelance web developers were a little harder to come by back then and most did not have a local testing environment set up. Of course, this was also before all the wonderful tools that I'm about to show you were even available. Back then, setting up a local testing environment was a bit of a pain.
Granted, the pain was totally worth it if you were able to get it working. But for many freelance web developers setting up a local testing environment back then was a time-consuming endeavor and was better done remotely. One thing to keep in mind is that a server is not a piece of hardware. I know when I talk about servers many of you are probably picturing small boxes that look similar to small computer towers sitting up on shelves.
Even I have that picture in my head sometimes and I know better! Setting up a server is more about the software than it is about the hardware. You can use your standard Windows or Mac computer; you just install some software and, voila!
You can actually install any other server-side language that you prefer. I prefer PHP, so that is what I am using. There are three primary methods from which you can choose for installing the three pieces I just mentioned web server, database server and server language: Use a single application that will install all three.
This is the easiest and fastest way to get a local test server up and running with the smallest headache, and a favorite method for many freelancers and new developers. However, this method can lack flexibility.
The components within depends on the vendor's set up. And if you're trying to get your local test server to match the production server as closely as possible, then this will make that very difficult. Install precompiled, ready-to-go binaries of each component. Though not quite as easy to do as the first option, this option does give you a little more freedom and a better chance that your local test server will closer match that of the live production server.
Although you may have to wait a little on updates and the like and you will be limited in terms of configuring extensions although you can choose which version of each component you would prefer , you will be able to pick and combine any of dozens of applications to build a closer match. This option allows you to do that.
Compile and install each of the three components yourself using their respective source codes. Now, this is the most flexible way to ensure that your local testing environment is as close to the live production environment as possible.
But this is also the most painful way to go — especially if you're trying to set up a local test server for the first time. You can tuck this method away in your memory bank for now, as I'll be focusing on the easier methods. There's no rule saying that you need both a local test server and a remote test server; this is just the set up that I generally recommend to my clients.
And it has to do with workflow and usage of each of the servers. First, my local test server is only accessible to me. I can go in there and fiddle around all day. I can send screenshots to my clients, notes and emails to my clients. I can even write out a detailed explanation about everything new that I've discovered and played with while on my local test server. But they cannot access the server itself. They can't hop onto their computer and take a peak at their website mid-development to see how far I've come.
They can't determine whether or not they like the look and feel of their site, the user-friendly experience or the workflow.
©2019 All rights reserved. SiteMap