If you’ve never heard of a CDN or you’re not sure exactly what it is, CDN is an acronym for Content Delivery Network. What a Content Delivery Network does, in very basic terms, is serve your site files from multiple data centers all over the world so that your visitors download files from a server near them and experience faster page loads. As a bonus, you get to experience reduced bandwidth use due to your content being cached at the various locations on the network.
How does it work? You change your domain’s name servers to point to the CDN, which then handles the requests for your site. When a request comes in to the CDN, here’s what it does:
That makes for a better visitor experience, since visitors are getting files from a local server. And it saves bandwidth on your Winhost account, since the files don’t have to come from the Winhost servers every time they are requested.
There are a lot of CDNs these days, and their setups vary in levels of difficulty. We’re offering a CDN that’s really easy to set up, and if you already have a SiteLock security plan for your site (and you really should, but that’s a separate article), you can add the basic CDN for free.
If you’re thinking that sounds great, but your site doesn’t contain much static content, SiteLock TrueShield CDN can also serve dynamic content from more than 25 data centers around the world via its Dynamic Content Caching system. It’s all completely automatic, but you have control over the cache and can purge files any time you need to, for instance when you update or change content on your site.
On average, sites using the SiteLock TrueShield CDN load 50% faster and use 40-70% less bandwidth.
The TrueShield CDN can also handle end to end encypted SSL (https) requests, and perfoms advanced CDN optimizing techniques, including content minification, image compression, session reuse optimization, “on the fly” file compression, TCP optimization & connection pre-pooling and progressive image rendering.
The TrueShield CDN isn’t only about speed, it also offers a layer of protection for your web applications. Does your site use WordPress? If so, you probably know that WordPress is a common target for exploits, and if someone gets into your WordPress installation, the cleanup can be a nightmare, not to mention the probable damage to your site and your reputation.
The SiteLock TrueShield CDN protects you against many web-based exploits with a Web Application Firewall, which blocks malicious bots from accessing your site, and depending on the plan you use, can protect your site against many SQL injections and cross site scripting. Whether your site uses a third party application that runs on a database or works with a database you designed and built, the Web Application Firewall can help keep you safe.
I know this sounds like a commercial for SiteLock, but we’re big fans of their service, and we’re able to offer you some really cool and useful tools through them. We see the damaging effects of website exploits every day, and as I mentioned, cleaning up after them is no fun. It’s either going to cost you time or money – sometimes both. So prevention, as they say, is the best medicine.
Broken image links are a common problem when you move your WordPress installation to another domain name or even to another subfolder. WordPress uses absolute paths to link images and objects to the page. The absolute path is usually defined during the initial WordPress setup process when you first configure WordPress. No problem right? You understand and know what absolute paths mean, and WordPress is working with no problems.
But what happens when you change the domain name for your WordPress site, or you move your WordPress site to a subfolder? Now you call on your WordPress site and some links are broken, images don’t show up, or some of the pages may come up with a 404 not found error. You right click on an image or object on the page and you can see the URL address does not match with the URL address on the address bar.
What a mess. Now what?
Fear not, this is actually a fairly easy fix!
There are a few easy way to fix this. The first thing to try is logging in to the WordPress admin section and changing the values in Settings > General. But sometimes the location change can make logging in to the admin section impossible, in which case you’ll want to try setting the new URL by either defining the SiteURL and Home variables in your configuration file, or going in to the database and changing them there.
Updating the wp-config.php file
Log into your site via FTP and look for the WordPress wp-config.php file. Open the file with a text manager such as NotePad and add these lines. Typically you should be able to add the lines under the connection string section of the configuration file.
/**Manually Define SiteURL and Home */
If you have just moved the WordPress files to a subfolder then the URL would look somewhat like this.
In my opinion, this is actually the easiest way to fix this. But some site owners don’t like to hard code values into the page, so the second way to solve the problem is to update the database. WordPress uses MySQL as it’s back end, and the SiteURL and HOME URL values are stored in there in plain text, so they’re easy to change.
Updating your WordPress database:
Log into your WordPress database. The table you will be looking for is wp_options. wp_ is the default prefix that WordPress will use in the initial setup. You may have used a different DB prefix during set up, but in general what you are looking for is the “Options” table.
Run this SELECT command against the Options table.
USE [Database Name]; SELECT option_name, option_value FROM wp_options WHERE option_name="home" OR option_name="siteurl";
You should see results similar to this.
To update the option_value column, just run this command against your database.
USE [Database Name]; UPDATE wp_options SET option_value="http://www.newdomain.com" WHERE option_name="siteurl" OR option_name="home";
If you are moving the WordPress site to a subfolder, the option_value would include the path to the subfolder:
That should be it. Either method will work. But don’t forget, at Winhost we can migrate your WordPress website for you. We’ll create and restore the MySQL database, update your connection string and make sure the absolute path it setup correctly. Simply contact our Support Department for more details on what we will need to migrate your site for you.
I’ve seen this before, a small or medium sized business pays a developer to build a NopCommerce website to run their online store. They pay several hundred – or even thousands – of dollars to get it up and running. Customized design and themes are added to give NopCommerce a custom look unique to the company. Everything goes well, the site is launched and the customer is happy. The developer has done their job and now they’ve moved on to their next project.
Then some months later the unthinkable happens, and the previously happy customer forgets the username or password to the NopCommerce admin account. They try to run through the NopCommerce password recovery process but it’s not working. They either don’t remember, or no longer have access to, the email address to the account. Regardless, the bottom line is that they do not know the credentials to your NopCommerce Admin account and the password recovery process is simply not working.
Luckily, if this ever happens to you there’s a work-around. You’ll need access to the SQL database that NopCommerce is using for the back end data source. You’re going to go directly to the database and change the password in the table that stores the admin account password.
But first you’ll need to create a new registered user in NopCommerce so that you will have a password that you can use to replace the admin account password. Log in to your NopCommerce site and click the “Register” link to set up a new user. You’re going to use the email address and password for this new user in the next steps.
Once the new user is created, log in to the NopCommerce database and search for the new user you just registered by running this SQL command against your database:
use [Database Name] go Select ID, Username, Password, PasswordSalt from dbo.Customer WHERE Usernamefirstname.lastname@example.org'
Replace email@example.com with the actual email address of the new user just registered. From the results of that command, copy the “Password” and “PasswordSalt” values.
Then run this update command:
use [Database Name] go Update dbo.Customer Set Password='<password copied from previous query>', PasswordSalt='<password salt copied from previous query>' WHERE ID='1';
The WHERE clause specifies the admin account, which will have ID value of ‘1’ since it is the first account created when setting up NopCommerce. Now you should be able to log in to the NopCommerce Admin account with the new password.
Here are the latest versions of the applications available through our App Installer tool:
Did you know that a single company owns more than 90 hosting company brands?
Most of them are linux hosts, but in the Windows hosting world they own Arvixe, HostGator, WebHost4Life, EasyCGI, ReadyHosting and a few others.
The corporation that owns all of these hosts is a publicly traded holdings company (NASDAQ: EIGI). Now, theoretically, a huge corporation could provide the world’s greatest hosting experience. After all, they have hundreds of millions of dollars to spend on infrastructure and staff. Theoretically.
That’s not the way it works though, at least not in the website hosting world. Which isn’t really surprising, since most publicly traded companies are primarily interested in one thing: making their investors happy. Which they do by maximizing profits, not necessarily by making customers happy.
Winhost is 100% employee owned and operated. We all work out of the same Los Angeles offices, including our technical support staff, many of whom have been here since day one. We show up every day because we love what we do: providing the best Windows server hosting available anywhere. We don’t answer to investors, we answer to our customers.
We’re not suggesting that all huge corporations are bad. But some of us have been in the web hosting industry for a long time, and have seen first hand how the quality of service and support typically decreases for the customer when their hosting company is gobbled up by the big fish in the pond. Sometimes dramatically so.
Which is a shame, since most of us only want a couple of simple things when it comes to our websites: reliability and a competent person to talk to when we have a problem.
If you miss “the old days” when you knew who your host was, we welcome you to join us here at the last of the independents: Winhost. Think of us as a lifeboat rowing away from a sinking ocean liner. Climb aboard. We always have room for one more.
Prompted by a few customers who are boldly going where no programmer has gone before, I’m proud to say that you can deploy an ASP.NET 5 (vNext) application to Winhost. Even though it’s in Beta right now, and this article will show you how.
ASP.NET 5 (vNext) represents a fundamental shift in how applications are going to be developed in the future as you will be able to deploy the application in any environment (Linux, Mac, or Windows). It no longer requires a Global Assembly Cache (GAC) as all the assemblies and runtime libraries are obtained using NuGet and then packaged with your application making it self-contained. They are placed in a special approot folder which also contains your source code. The approot folder replaces the functionality of the App_Code or Bin folders. Another folder named wwwroot is also created which contains static files (e.g. html, css, images, etc) and is where your application is launched from.
Because it’s in Beta, I highly recommend that you pay attention to Microsoft’s Roadmap for the release schedule as I’m sure things will have changed by the time it’s officially released. And for the same reason, I can only say these instructions are applicable up to Beta6 in case things change in the future. I’m afraid this guide only covers the publishing portion. If you need help with developing an ASP.NET 5 (vNext) application and don’t know where to start, please make sure you visit the Official Website. I’m also sorry to say that Web Deploy publishing is not supported at this time, only FTP publishing.
Publishing to a sub-directory at Winhost:
A vNext application can only be created using Visual Studio 2015 Professional or higher, so you’ll need to obtain a copy, install it, and then launch the program.
A) Create a new project by selecting File -> New -> Project…
B) Under Visual C# (or the language of your choice), select Web and to the right, select ASP.NET Web Application. Give your project a name if you’d like.
C) In the New ASP.NET Project window, select Web Application for the ASP.NET 5 Preview Template and uncheck Host in the cloud under Microsoft Azure. Click OK continue.
E) Since this is sample application, we can just publish it without making any changes. Select Build -> Publish on the menu bar.
F) In the Profile section, select File System.
G) Name the profile.
H) In the Connection section, set the Target location to a directory that is easily accessible and click on the Next> button.
I) In the Settings section, set the Configuration to Release. For the Target DNX Version, it should match the framework your application is written in. DNX stands for .NET Execution Environment which allows your application to be deployed across different platforms (Windows, Mac and Linux). For more information, you can consult the DNX documentation.
If you plan to use the 64 bit versions of the CLRs, you’ll need to open up a support ticket to request that we disable 32-bit support for your application pool, otherwise, it won’t work properly. Uncheck Publish using Powershell script and click on the Next> button.
J) Click the Publish button to start.
K) Once the publishing has finished, you will see the two folders I mentioned earlier, approot and wwwroot. In the wwwroot folder, there is a web.config file that is used to direct the application on how to start. To protect the approot folder from being viewed, we’ll use Request Filtering, create a web.config file with the following markup, and place it in the root level of the site. Some applications require “Full” trust in order to run, so we’ll go ahead and add that to the web.config file as well.
<?xml version="1.0" encoding="UTF-8"?> <configuration> <system.web> <trust level="Full" /> </system.web> <system.webServer> <security> <requestFiltering> <hiddenSegments> <add segment="approot" /> </hiddenSegments> </requestFiltering> </security> </system.webServer> </configuration>
L) Upload these two folders to your site and ignore the other files. Create an Application Starting Point for the wwwroot folder using the tool in the Winhost Control Panel.
Voila! Your application works but only from a sub-directory (i.e. http://www.mysite.com/wwwroot).
Publishing to the root at Winhost:
If you want your application to run from the root of your site, you just need to make a few modifications post publishing. Locate the project.json file in /approot/src/projectname directory and open it. Change the second line from “webroot”: “../../../wwwroot” to “webroot”: “../../..” Move the contents of the wwwroot directory up one file level. You’ll also need to merge the two web.config files and change the following lines:
<add key=”runtime-path” value=”..\approot\runtimes” />
<add key=”runtime-path” value=”.\approot\runtimes” />
<add key=”dnx-app-base” value=”..\approot\src\aspnet5demo” />
<add key=”dnx-app-base” value=”.\approot\src\aspnet5demo” />
Your application now works from the root.
Ftp’ing through Visual Studio
You can also use FTP to publish your files within Visual Studio by creating a publishing profile. Take any text editor, create a file and name it with a .publishsettings extension (e.g. my.publishsettings), and paste the following XML markup into the page:
<?xml version="1.0" encoding="utf-8"?> <publishData> <publishProfile profileName="FTP" publishMethod="FTP" publishUrl="ftp://ftpaddress" userName="username" userPWD="password" destinationAppUrl="http://httpaddress" /> </publishData>
Replace ftpaddress, username, password, and httpaddress with the appropriate values. Save the file. At Step F, instead of choosing File System, select the Import option instead and load the my.publishsettings file. Follow the rest of the steps to finish configuring the application. I wouldn’t recommend this method since you’ll need to download some files to make edits and then re-upload them, however, I wanted to make you aware that it is possible.
Please also take note that an ASP.NET 5 (vNext) application must be deployed to an IIS 7.5 or higher server.
On July 14, 2015, Microsoft ended their support of Windows 2003. That means they won’t be issuing any more security patches or updates.
If your website is still hosted on a Windows 2003 server, it’s time to move away from that unsupported technology, and Winhost is here as a Windows hosting option for you.
Winhost has never offered hosting on Windows 2003 servers, so we have no legacy O/S servers to contend with. We support all the modern Windows Stack including ASP.NET and SQL database, but we also continue to support legacy technologies like Classic ASP and Access databases.
It’s the best of both worlds, so come and enjoy it.
The latest versions of the following applications are now available through our App Installer tool: