- Acquire DotNetNuke
- Go to http://www.dotnetnuke.com/ and login (note: if you're not registered, then you'll have to register before you can login)
- Click the "DOWNLOAD" icon at the top of the page
- Download the edition of your choice (I chose Community)
- Unzip the file to the directory of your choice
- Virtual directory setup
- Login to GoDaddy
- Hover over "Hosting" on the menu bar and click the "My Hosting Account" link
- Click "Manage Account" next to the site to which you want to install DNN. This will take you to GoDaddy's Hosting Control Center.
- Hover over the "Content" tab and click the "File Manager" link
- Select the "[Root]" row by clicking on it or checking the checkbox
- Click the "Permissions" icon on the toolbar
- Check the "Read", "Write", and "Reset all children to inherit" and click OK (this needs to occur because DotNetNuke writes to its directory and sub-directories for many reasons, the most common is module installation)
- Database setup
- In GoDaddy's Hosting Control Center, hover over the "Databases" tab and click the "SQL Server" link
- Click the "Create Database" button
- In the description type something descriptive like "www.mydomain.com DotNetNuke Database"
- Check the DSN and ASP Schema checkboxes (this tells GoDaddy's database creation script to create a Data Source Name for the database and to Create the tables for the ASP Schema - e.g. aspnet_Applications, aspnet_Roles, etc.)
- (Optional) If you want remote admin access to the database, check the "Yes" radio button under "Allow Direct Database Access" (this allows external access to the database - e.g. you can connect to it using SQL Server Management Studio on your own PC)
- Enter a name for the database in the "SQL Server Database/User Name" field - e.g. mydomaindnn (this will be the name of the database and the user name for used for DNN's access)
- Pick a good password, but be mindful of GoDaddy's password requirements. Write down this password as you'll need it to edit the web.config in a future step.
- (Optional) If you'd like to create an user with read-only access this database, fill out the remaining fields correlating to "Read-Only User"
- Click OK (You'll be taken back to teh SQL Server databases page and the status of your database will be "Pending Setup" - this should only be the case for a few minutes)
- Click the "Edit/View Details" icon for your database in the "Actions" column. This page contains the values you'll need for changing the web.config in the next step.
- Web.Config
- On your PC, go to the directory where you unzipped the DNN installation files.
- Rename web.config to original-web.config
- Rename release.config to web.config
- Open web.config in your favorite editor
- In the conectionStrings section, fully comment out the SQLExpress connection string (it contains "Data Source=.\SQLExpress"), and uncomment the SQL Server connection string (it contains "Server=(local)"). Change the SQL Server connection string include the database values seen on GoDaddy (Server is Host Name; Database is Database Name; uid is User Name and pwd is the password you entered for this user when you set up the datbase).
- Repeat the above step for the connections strings found in the appSettings section just a few lines below.
- Upload via FTP
- Configure your FTP clint (FileZilla, or CuteFtp, or the like) to point to ftp.mydomain.com, with your GoDaddy username/passoword (or another FTP user for whom you've register FTP credentials through the GoDaddy Control Center).
- Connect
- Once connected, you can delete everything in the root except the _db_backups and _hcc_thumbs directories.
- This upload the contents of the directory to which you unzipped the DNN installation files.
- You are ready to install
- Navigate to the www.mydomain.com
- Follow the steps to walk through creating your site (Note: choosing the Auto option is recommended.)
- For SMTP settings, use
server: relay-hosting.secureserver.net
basic
username: emailuser@mydomain.com
password: [emailuser's email password]
* Make sure to Test the settings before you move on!
Showing posts with label web. Show all posts
Showing posts with label web. Show all posts
Sunday, November 15, 2009
Manually Installing DotNetNuke on GoDaddy
These steps detail the process of manually installing DotNetNuke to the root of an empty GoDaddy hosted domain.
Tuesday, January 29, 2008
Web Applications are Overrated
For years we've been told that web apps are the way of the future. But are they really? The answer is "probably not". Think about where web applications are going. You don't know where they're going? We'll let's think about where they've been.
The Stateless Abyss
For almost 20 years now, web applications have lived in the stateless depths of the World Wide Web, thanks to that wonderful little protocol, HTTP. HTTP's request/response nature allowed for simple and straight-forward communication back in the day, when all we really wanted was to ask another machine on the web for a resource.
The Dynamic Shift
As the Web grew in popularity, we started placing more and more demands on the resources for which we asked. We started making the dog do tricks. We wanted more "interactivity"; static text and images were no longer enough; we now needed the ability to customize the resource and create "dynamic content" with each request. We wanted to conduct business and stream media all over a stateless channel, where each transaction had no knowledge of previous ones.
The Stateful Revolution
Soon, having the dog roll over or shake hands was not enough as well. The time came for stateful transactions. We now want to keep track of whom is logged in, what he/she has done and where he/she has been. We want state. Only now, we're making the dog walk a tight-rope and juggle chainsaws. We've begun to do things like stuff variable values in responses and re-collect them on the next request or write database records to keep track of transaction state on the web server; all to mimic stateful transactions. Dozens of web frameworks have surfaced, many having a mechanism built-in to get around the stateless nature of HTTP. We now have technologies that effectively mix web and desktop technologies, something I like to call "webtop clients", manifest in Adobe Flash Player, Java Applets, and Microsoft Silverlight.
The Pattern
Do you see the pattern? Since the inception of the Web, web applications have evolved significantly; from static content to dynamic content, from statelessness to statefulness, from browser-only technology to browser-desktop mixture technologies. However, their evolution is not toward something new and unseen, but to something all too familiar, the thick client.
With today's frameworks for desktop application development and deployment, the justification for many of today's web applications, especially web apps internal to a company, are no longer legit. Take a look at Apple's iTunes; everything Apple flows through that application. As for deployment, Microsoft's ClickOnce for .NET Windows applications and Sparkle for Cocoa applications make deployment and updates so easy, it's ridiculous. Don't get me wrong, web applications do have their place, but the number of scenarios for which they are the optimal choice is dwindling; sure they can be used for nearly everything, but what's the point? It all comes down to the following question: in a particular situation, what problem does a web application solve that a desktop application does not? When you realize how many times you can't find any, you'll realize that web applications are overrated.
The Stateless Abyss
For almost 20 years now, web applications have lived in the stateless depths of the World Wide Web, thanks to that wonderful little protocol, HTTP. HTTP's request/response nature allowed for simple and straight-forward communication back in the day, when all we really wanted was to ask another machine on the web for a resource.
The Dynamic Shift
As the Web grew in popularity, we started placing more and more demands on the resources for which we asked. We started making the dog do tricks. We wanted more "interactivity"; static text and images were no longer enough; we now needed the ability to customize the resource and create "dynamic content" with each request. We wanted to conduct business and stream media all over a stateless channel, where each transaction had no knowledge of previous ones.
The Stateful Revolution
Soon, having the dog roll over or shake hands was not enough as well. The time came for stateful transactions. We now want to keep track of whom is logged in, what he/she has done and where he/she has been. We want state. Only now, we're making the dog walk a tight-rope and juggle chainsaws. We've begun to do things like stuff variable values in responses and re-collect them on the next request or write database records to keep track of transaction state on the web server; all to mimic stateful transactions. Dozens of web frameworks have surfaced, many having a mechanism built-in to get around the stateless nature of HTTP. We now have technologies that effectively mix web and desktop technologies, something I like to call "webtop clients", manifest in Adobe Flash Player, Java Applets, and Microsoft Silverlight.
The Pattern
Do you see the pattern? Since the inception of the Web, web applications have evolved significantly; from static content to dynamic content, from statelessness to statefulness, from browser-only technology to browser-desktop mixture technologies. However, their evolution is not toward something new and unseen, but to something all too familiar, the thick client.
With today's frameworks for desktop application development and deployment, the justification for many of today's web applications, especially web apps internal to a company, are no longer legit. Take a look at Apple's iTunes; everything Apple flows through that application. As for deployment, Microsoft's ClickOnce for .NET Windows applications and Sparkle for Cocoa applications make deployment and updates so easy, it's ridiculous. Don't get me wrong, web applications do have their place, but the number of scenarios for which they are the optimal choice is dwindling; sure they can be used for nearly everything, but what's the point? It all comes down to the following question: in a particular situation, what problem does a web application solve that a desktop application does not? When you realize how many times you can't find any, you'll realize that web applications are overrated.
Subscribe to:
Posts (Atom)