|
|
| ||||||||||||||
 |
Often times when switching hosts, it's imperative that there is no down time. This process will outline how to move your website to a Software
Projects server.
Step 1 - HTML/PHP/Media file migration
Many basic hosting packages only allow FTP access. In those cases, you may be stuck transferring your site to your computer and then uploading those
files to your new Software Projects hosting account.
However, if you have shell access with your hosting account, there is a quick and easy way to move your files from your current host to your Software
Projects hosting account using tar and SSH. See the following command as an example:
Breaking that down, the first part:
"tar -czpf - ./" - this part of the command tells the system to tar everything in the current directory. Assuming you were in your root directory,
this wouldn't have to change at all. Otherwise replace the './' with the path to your root directory.
"| ssh -l[user] [ip_address]" - this part tells the server to send the tar contents through SSH. You would replace "[user]" with the username for SSH
and "[ip_address]" with the ip address of the server you are transferring to (the Software Projects server, which you could get from your account
manager or engineer).
"tar -xzpf - -C /home/yourdomain.com/htdocs &" - this part tells the remote server (Software Projects) that it should uncompress the tar data sent
over SSH into the directory specified. In the above example '/home/yourdomain.com/htdocs'. You would get this information from your Software Projects
account manager or engineer.
Step 2 - MySQL Database migration
Typically the best way to transfer your database to Software Projects is to use the mysqldump program. This is only possible if you have shell access
on your hosting account. It is possible to move the data in a single command, like so:
A quick breakdown:
"mysqldump -h[local_db_host] -u[local_db_user] -p[local_db_password] --all-databases" - this part of the command runs the mysqldump program which
connects to your local database and dumps all databases. You would replace [local_db_host] with your current database host, [local_db_user] with your
current database username and [local_db_password] with your local database password. The '--all-databases' option tells the program to dump all the
databases. You can delete that part and replace it with a certain database name if you only want to transfer that database, like so:
"| mysql -h[database_host] -u[database_user] -p[database_password] -C" - this part of the command tells the server to send the dump created by
mysqldump to the remote mysql server and import that dump into the database server. You would replace [database_host], [database_user] and
[database_password] with the credentials given to you by your Software Projects account manager or engineer. The '-C' option tells mysql to "Compress
all information sent between the client and the server if both support compression". If you specify a database name (dbname) in mysqldump portion of
the command, you would want to specify that in the mysql portion of the command, something like:
Step 3 - SSL Setup with Nginx
Setting up SSL with Nginx is very similar to apache. You create 2 files, a key file and your crt file. The key file contains the key you received when purchasing the SSL certificate for your domain. The crt file contains 2 certificates that are combined into a single file. This is your SSL certificate you received combined with the identifier certificate you received from the issuing company. For instance if you purchased a certificate from GoDaddy you may receive 3 files. The key, the certificate and the godaddy intermediate bundle (another certificate). You would combine the certificate for your domain with the intermediate key with cat command:
You would place this file somewhere in the filesystem, we use /etc/nginx/. You would also place your key file in that directory. Then you would need to create a new location directive in nginx.conf for this secure server and specify these files. Here is an example:
You would replace '/home/yourdomain.com/htdocs' with the root of the website on the server. You would replace /etc/nginx/yourdomain.com.crt and /etc/nginx/yourdomain.com.nokey with the names of your combined crt file and key file, respectively. Restart nginx and you should be all set.
Note about sessions across sub-domains:
When trying to use sessions across sub-domains, you may need to add something like the following when starting your session:
This tells the session that it should work on "*.yourdomain.com" so that pages with domains such as www.yourdomain.com/index.php and yourdomain.com/index.php could use the same session.
Note about timezones:
Many times the server you are hosting on and your own timezone are different, and for things like timestamps or scripts, you may want to change the timezone in those scripts to match your timezone rather than the one the server uses. In PHP you would use the putenv function, such as:
The above would set your timezone in the script to Eastern Standard Time in the USA.
Note about password protection:
You can learn how to password protect your directories under nginx with the following tutorial:
http://www.softwareprojects.com/reso...your-1518.html
Projects server.
Step 1 - HTML/PHP/Media file migration
Many basic hosting packages only allow FTP access. In those cases, you may be stuck transferring your site to your computer and then uploading those
files to your new Software Projects hosting account.
However, if you have shell access with your hosting account, there is a quick and easy way to move your files from your current host to your Software
Projects hosting account using tar and SSH. See the following command as an example:
tar -czpf - ./ | ssh -l[user] [ip_address] tar -xzpf - -C /home/yourdomain.com/htdocs &
Breaking that down, the first part:
"tar -czpf - ./" - this part of the command tells the system to tar everything in the current directory. Assuming you were in your root directory,
this wouldn't have to change at all. Otherwise replace the './' with the path to your root directory.
"| ssh -l[user] [ip_address]" - this part tells the server to send the tar contents through SSH. You would replace "[user]" with the username for SSH
and "[ip_address]" with the ip address of the server you are transferring to (the Software Projects server, which you could get from your account
manager or engineer).
"tar -xzpf - -C /home/yourdomain.com/htdocs &" - this part tells the remote server (Software Projects) that it should uncompress the tar data sent
over SSH into the directory specified. In the above example '/home/yourdomain.com/htdocs'. You would get this information from your Software Projects
account manager or engineer.
Step 2 - MySQL Database migration
Typically the best way to transfer your database to Software Projects is to use the mysqldump program. This is only possible if you have shell access
on your hosting account. It is possible to move the data in a single command, like so:
mysqldump -h[local_db_host] -u[local_db_user] -p[local_db_password] --all-databases | mysql -h[database_host] -u[database_user] -p[database_password] -C
A quick breakdown:
"mysqldump -h[local_db_host] -u[local_db_user] -p[local_db_password] --all-databases" - this part of the command runs the mysqldump program which
connects to your local database and dumps all databases. You would replace [local_db_host] with your current database host, [local_db_user] with your
current database username and [local_db_password] with your local database password. The '--all-databases' option tells the program to dump all the
databases. You can delete that part and replace it with a certain database name if you only want to transfer that database, like so:
mysqldump -h[local_db_host] -u[local_db_user] -p[local_db_password] dbname
"| mysql -h[database_host] -u[database_user] -p[database_password] -C" - this part of the command tells the server to send the dump created by
mysqldump to the remote mysql server and import that dump into the database server. You would replace [database_host], [database_user] and
[database_password] with the credentials given to you by your Software Projects account manager or engineer. The '-C' option tells mysql to "Compress
all information sent between the client and the server if both support compression". If you specify a database name (dbname) in mysqldump portion of
the command, you would want to specify that in the mysql portion of the command, something like:
mysqldump -h[local_db_host] -u[local_db_user] -p[local_db_password] mydatabase | mysql -h[database_host] -u[database_user] -p[database_password] -C mydatabase
Step 3 - SSL Setup with Nginx
Setting up SSL with Nginx is very similar to apache. You create 2 files, a key file and your crt file. The key file contains the key you received when purchasing the SSL certificate for your domain. The crt file contains 2 certificates that are combined into a single file. This is your SSL certificate you received combined with the identifier certificate you received from the issuing company. For instance if you purchased a certificate from GoDaddy you may receive 3 files. The key, the certificate and the godaddy intermediate bundle (another certificate). You would combine the certificate for your domain with the intermediate key with cat command:
cat certificate.crt godaddy_bundle.crt > yourdomain.com.crt
You would place this file somewhere in the filesystem, we use /etc/nginx/. You would also place your key file in that directory. Then you would need to create a new location directive in nginx.conf for this secure server and specify these files. Here is an example:
# HTTPS server
#
server {
listen 443;
server_name yourdomain.com;
# set SSL vars
ssl on;
ssl_certificate /etc/nginx/yourdomain.com.crt;
ssl_certificate_key /etc/nginx/yourdomain.com.nokey;
ssl_session_timeout 5m;
# pass all scripts to FastCGI server listening on 127.0.0.1:9000
#
location /
{
# set the doc root
root /home/yourdomain.com/htdocs;
index index.php;
# pass to FastCGI
fastcgi_pass 127.0.0.1:8888;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /home/yourdomain.com/htdocs/$fastcgi_script_name;
fastcgi_intercept_errors on;
include /etc/nginx/fastcgi_top.conf;
fastcgi_param DOCUMENT_ROOT /home/yourdomain.com/htdocs/;
fastcgi_param HTTPS on;
include /etc/nginx/fastcgi_bottom.conf;
}
}
#
server {
listen 443;
server_name yourdomain.com;
# set SSL vars
ssl on;
ssl_certificate /etc/nginx/yourdomain.com.crt;
ssl_certificate_key /etc/nginx/yourdomain.com.nokey;
ssl_session_timeout 5m;
# pass all scripts to FastCGI server listening on 127.0.0.1:9000
#
location /
{
# set the doc root
root /home/yourdomain.com/htdocs;
index index.php;
# pass to FastCGI
fastcgi_pass 127.0.0.1:8888;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /home/yourdomain.com/htdocs/$fastcgi_script_name;
fastcgi_intercept_errors on;
include /etc/nginx/fastcgi_top.conf;
fastcgi_param DOCUMENT_ROOT /home/yourdomain.com/htdocs/;
fastcgi_param HTTPS on;
include /etc/nginx/fastcgi_bottom.conf;
}
}
You would replace '/home/yourdomain.com/htdocs' with the root of the website on the server. You would replace /etc/nginx/yourdomain.com.crt and /etc/nginx/yourdomain.com.nokey with the names of your combined crt file and key file, respectively. Restart nginx and you should be all set.
Note about sessions across sub-domains:
When trying to use sessions across sub-domains, you may need to add something like the following when starting your session:
session_set_cookie_params(time()+3600*10,"/",".yourdomain.com");
This tells the session that it should work on "*.yourdomain.com" so that pages with domains such as www.yourdomain.com/index.php and yourdomain.com/index.php could use the same session.
Note about timezones:
Many times the server you are hosting on and your own timezone are different, and for things like timestamps or scripts, you may want to change the timezone in those scripts to match your timezone rather than the one the server uses. In PHP you would use the putenv function, such as:
putenv ('TZ=EST+05EDT');
The above would set your timezone in the script to Eastern Standard Time in the USA.
Note about password protection:
You can learn how to password protect your directories under nginx with the following tutorial:
http://www.softwareprojects.com/reso...your-1518.html
How to recompile nginx and replace current binary, with no down-time:
Follow the same generic steps as a regular install initially.
1. Download and untar the nginx source if you don't have it on your machine already.
2. Make a copy of your current nginx binary and conf. The installation usually does this automatically, but just to be safe.
3. Run the "./configure" command. For example if you wanted to add SSL support to nginx, you would have a configure statement such as:
If you have other options you need you can add those as well. To see what your current nginx has configured, run the binary with -V flag ie.
4. run: "make install clean" This will install the new binary in place of the old one and makes a backup of the old one.
These steps are more specific to replacing a current install without down-time:
5. Send a USR2 signal to the current pid file, something like:
This causes nginx master process that was running to rename its pid and start the new binary. Both will run simultaneously.
8. To disable the old workers, send the old master process a WINCH signal. If your pid is '123' that would be something like:
9. Now you can test the new nginx process to see if it's working. If it is, you can kill the old master process to allow the new one to take over. If the old master process had a PID of '123' you would do this:
If you find your new binary isn't working correctly, maybe due to a mistake during configuration, you can revert back to the old master process by doing the following. Assume your old master process has a PID of '123' and the new master process has a PID of '321':
You can find some additional information about nginx upgrades and signals here:
http://wiki.codemongers.com/NginxCommandLine#utnbotf
Follow the same generic steps as a regular install initially.
1. Download and untar the nginx source if you don't have it on your machine already.
2. Make a copy of your current nginx binary and conf. The installation usually does this automatically, but just to be safe.
"cp /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx_old"
"cp /usr/local/nginx/conf/nginx.conf /usr/local/nginx/conf/nginx.conf.old"
"cp /usr/local/nginx/conf/nginx.conf /usr/local/nginx/conf/nginx.conf.old"
3. Run the "./configure" command. For example if you wanted to add SSL support to nginx, you would have a configure statement such as:
./configure --with-http_ssl_module --with-openssl=/path/to/openssl_src
If you have other options you need you can add those as well. To see what your current nginx has configured, run the binary with -V flag ie.
"/usr/local/nginx/sbin/nginx -V"
4. run: "make install clean" This will install the new binary in place of the old one and makes a backup of the old one.
These steps are more specific to replacing a current install without down-time:
5. Send a USR2 signal to the current pid file, something like:
"kill -USR2 `cat /usr/local/nginx/logs/nginx.pid`".
This causes nginx master process that was running to rename its pid and start the new binary. Both will run simultaneously.
8. To disable the old workers, send the old master process a WINCH signal. If your pid is '123' that would be something like:
"kill -WINCH 123"
9. Now you can test the new nginx process to see if it's working. If it is, you can kill the old master process to allow the new one to take over. If the old master process had a PID of '123' you would do this:
"kill -QUIT 123"
If you find your new binary isn't working correctly, maybe due to a mistake during configuration, you can revert back to the old master process by doing the following. Assume your old master process has a PID of '123' and the new master process has a PID of '321':
"kill -HUP 123" - this will restart the workers under the old master process
"kill -QUIT 321" - shuts down the new master process workers
"kill -TERM 321" - shuts down the new master process
"kill -QUIT 321" - shuts down the new master process workers
"kill -TERM 321" - shuts down the new master process
You can find some additional information about nginx upgrades and signals here:
http://wiki.codemongers.com/NginxCommandLine#utnbotf
Protecting a directory on your website with HTTP Authentication can be done in a few easy steps.
First, you need to create a user/password combination using a program called htpasswd. We have a script created that allows you to do just that with ease. Simply go to this url and type in your username and password to get the encrypted user/pass you will need to place into a file.
http://www.softwareprojects.com/serv...tehtpasswd.php
After that you have to create a file under the directory you want protected and place that encrypted username/password into it, we will call it htaccessfile in this example. At that point you are ready to make changes to the conf file.
Once you have your username and password encrypted, you would access the 'nginx.conf' file in your root website directory. This file tells our webserver how to treat the files/directories on your page. It is in here that you will make the necessary changes to enable password protection on whichever directory you may want. You need to add several lines to your 'nginx.conf':
In the above example, you would replace 'mydomain.com' with your domain, 'protectthisdirectory' with the directory you are tying to place a password on, and 'htaccessfile' with the name of your password file.
Once you make these changes, our system will automatically refresh the web-server and password protection would be enabled within about 2 minutes.
First, you need to create a user/password combination using a program called htpasswd. We have a script created that allows you to do just that with ease. Simply go to this url and type in your username and password to get the encrypted user/pass you will need to place into a file.
http://www.softwareprojects.com/serv...tehtpasswd.php
After that you have to create a file under the directory you want protected and place that encrypted username/password into it, we will call it htaccessfile in this example. At that point you are ready to make changes to the conf file.
Once you have your username and password encrypted, you would access the 'nginx.conf' file in your root website directory. This file tells our webserver how to treat the files/directories on your page. It is in here that you will make the necessary changes to enable password protection on whichever directory you may want. You need to add several lines to your 'nginx.conf':
location ^~ /protectthisdirectory/ {
root /home/mydomain.com/htdocs;
index index.php index.html index.htm *;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /home/mydomain.com/htdocs/$fastcgi_script_name;
include /etc/nginx/fastcgi_top.conf;
fastcgi_param DOCUMENT_ROOT /home/mydomain.com/htdocs/;
include /etc/nginx/fastcgi_bottom.conf;
if ($uri ~ \.php$)
{
fastcgi_pass 127.0.0.1:8888;
}
auth_basic "Restricted";
auth_basic_user_file /home/mydomain.com/htdocs/protectthisdirectory/htaccessfile;
}
root /home/mydomain.com/htdocs;
index index.php index.html index.htm *;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /home/mydomain.com/htdocs/$fastcgi_script_name;
include /etc/nginx/fastcgi_top.conf;
fastcgi_param DOCUMENT_ROOT /home/mydomain.com/htdocs/;
include /etc/nginx/fastcgi_bottom.conf;
if ($uri ~ \.php$)
{
fastcgi_pass 127.0.0.1:8888;
}
auth_basic "Restricted";
auth_basic_user_file /home/mydomain.com/htdocs/protectthisdirectory/htaccessfile;
}
In the above example, you would replace 'mydomain.com' with your domain, 'protectthisdirectory' with the directory you are tying to place a password on, and 'htaccessfile' with the name of your password file.
Once you make these changes, our system will automatically refresh the web-server and password protection would be enabled within about 2 minutes.
This step by step tutorial is everything you need to install MySQL 5.1 (from source) on a virgin FreeBSD 4.x - 7.x machine.
Step 1: Install wget
Step 2: Download MySQL 5.1 source code
Step 3: Create mysql user
Follow the prompts to create a mysql user and mysql group with a default directory of /usr/local/mysql
Step 4: Compile and Install MySQL with InnoDB support
Step 5: Install default MySQL tables
Step 6: Startup MySQL and connect to it
Step 7: Set MySQL to start automatically when the machine reboots
Save the file below under /usr/local/etc/rc.d and call it mysqlstart.sh
Mark it as an executable
Step 8: Customizations
The following steps are optional.
By this point you should have MySQL installed and running on your new FreeBSD machine.
The customizations below are things that we do here at SoftwareProjects and are designed to get the most juice out of MySQL 5.1 in our environment.
All of our MySQL database machines run on FreeBSD 6/7 with a minimum of 4GB memory.
Shutdown the MySQL database
Move the data directory to /usr/local/mysql/data
Save our custom MySQL configuration file under /etc/my.cnf
Note: Be sure to assign a unique server-id and note the auto-increment field - this is useful for master/master setups.
Step 9: Lift process size restrictions
FreeBSD limits process max size in memory to 512MB. We're going to want to use more for MySQL.
To lift FreeBSD process size restrictions, we have to update /boot/loader.conf with:
And then reboot the machine
Step 10: Populate database with data
Typically when we install a new database server, we want to populate it with data from another database.
The absolute easiest way to populate a secondary MySQL database machine with data from another MySQL database, is by using a script called InnoDBBackup by the makers of InnoDB.
Install both ibbackup and the Perl innobackup script on the master database machine (the one you are looking to transfer data from)
create a backup of the database (the great thing about this is you never have to take the database down):
Once the backup completes, transfer all the data over from the master to this new machine we are setting up -
On the new machine we are setting up, create a new directory to hold the backup:
On the master machine, issue this tar command:
Once the tar is done, copy ibbackup and innobackup to the destination machine under /usr/tmp and run this command:
Replace the 2008-05-02... with the name of your backup folder
Step 1: Install wget
cd /usr/ports/ftp/wget
make
make install
make
make install
Step 2: Download MySQL 5.1 source code
mkdir /usr/tmp
cd /usr/tmp
wget "http://dev.mysql.com/get/Downloads/MySQL-5.1/mysql-5.1.24-rc.tar.gz/from/http://mysql.he.net/"
tar xvzf mysql-5.1.24-rc.tar.gz
cd /usr/tmp
wget "http://dev.mysql.com/get/Downloads/MySQL-5.1/mysql-5.1.24-rc.tar.gz/from/http://mysql.he.net/"
tar xvzf mysql-5.1.24-rc.tar.gz
Step 3: Create mysql user
adduser
Follow the prompts to create a mysql user and mysql group with a default directory of /usr/local/mysql
Step 4: Compile and Install MySQL with InnoDB support
cd /usr/tmp/mysql-5.1.24-rc
./configure --with-innodb
make all
make install
./configure --with-innodb
make all
make install
Step 5: Install default MySQL tables
cd /usr/local/bin
./mysql_install_db
cd /usr/local
chown -R mysql:mysql var
./mysql_install_db
cd /usr/local
chown -R mysql:mysql var
Step 6: Startup MySQL and connect to it
/usr/local/bin/mysqld_safe &
/usr/local/bin/mysql
/usr/local/bin/mysql
Step 7: Set MySQL to start automatically when the machine reboots
Save the file below under /usr/local/etc/rc.d and call it mysqlstart.sh
/usr/local/bin/mysqld_safe &
Mark it as an executable
chmod 755 /usr/local/etc/rc.d/mysqlstart.sh
Step 8: Customizations
The following steps are optional.
By this point you should have MySQL installed and running on your new FreeBSD machine.
The customizations below are things that we do here at SoftwareProjects and are designed to get the most juice out of MySQL 5.1 in our environment.
All of our MySQL database machines run on FreeBSD 6/7 with a minimum of 4GB memory.
Shutdown the MySQL database
/usr/local/bin/mysqladmin shutdown
Move the data directory to /usr/local/mysql/data
mv /usr/local/var /usr/local/mysql/data
Save our custom MySQL configuration file under /etc/my.cnf
Note: Be sure to assign a unique server-id and note the auto-increment field - this is useful for master/master setups.
Step 9: Lift process size restrictions
FreeBSD limits process max size in memory to 512MB. We're going to want to use more for MySQL.
To lift FreeBSD process size restrictions, we have to update /boot/loader.conf with:
sl_aacu_load="YES"
kern.maxdsiz="2073741824" # 2GB
kern.dfldsiz="2073741824" # 2GB
#kern.maxssiz="536870912" # 512MB
kern.maxdsiz="2073741824" # 2GB
kern.dfldsiz="2073741824" # 2GB
#kern.maxssiz="536870912" # 512MB
And then reboot the machine
Step 10: Populate database with data
Typically when we install a new database server, we want to populate it with data from another database.
The absolute easiest way to populate a secondary MySQL database machine with data from another MySQL database, is by using a script called InnoDBBackup by the makers of InnoDB.
Install both ibbackup and the Perl innobackup script on the master database machine (the one you are looking to transfer data from)
create a backup of the database (the great thing about this is you never have to take the database down):
./innobackup /etc/my.cnf /usr/local/mysql/databackup
Once the backup completes, transfer all the data over from the master to this new machine we are setting up -
On the new machine we are setting up, create a new directory to hold the backup:
mkdir /usr/local/mysql/databackup
chmod a+rw /usr/local/mysql/databackup
chmod a+rw /usr/local/mysql/databackup
On the master machine, issue this tar command:
tar -czpf - /usr/local/mysql/databackup --exclude mysql | ssh -lUSERNAME NEWHOST.COM tar -xzpf - -C /usr/local/mysql/databackup
Once the tar is done, copy ibbackup and innobackup to the destination machine under /usr/tmp and run this command:
./innobackup --apply-log /etc/my.cnf /usr/local/mysql/databackup/2008-05-02_09-34-03/backup-my.cnf
Replace the 2008-05-02... with the name of your backup folder
aMember is one of the most popular membership scripts, widely used by many information marketers.
aMember supports all major payment gateways and delivers a password protected members-only section of your website.
As part of a recent project we had to implement a way to automatically add new users to aMember on demand.
Unfortunately, aMember doesn't seem to have a documented API so I had to do some database-level hacking.
The two tables you need to update are: amember_members and amember_payments. The members table contains information about every single user in aMember. The payments table associates members with products.
The function below creates a set of amember_members and amember_payments record, adding a new member to the system with a single payment:
Notes:
1. To simplify login, new members are configured with their emailaddress as both the login and password. Make sure you ask users to change their password the first time they login.
2. Product_id is the unique amember_products ID identifying the product you would like to associate new members with
aMember supports all major payment gateways and delivers a password protected members-only section of your website.
As part of a recent project we had to implement a way to automatically add new users to aMember on demand.
Unfortunately, aMember doesn't seem to have a documented API so I had to do some database-level hacking.
The two tables you need to update are: amember_members and amember_payments. The members table contains information about every single user in aMember. The payments table associates members with products.
The function below creates a set of amember_members and amember_payments record, adding a new member to the system with a single payment:
<?php
function aMemberAddMember($emailaddress, $firstname, $lastname, $product_id)
{
mysql_query("INSERT INTO amember_members (login,pass,email,name_f,name_l,added,data,status) values (\"".
addslashes($emailaddress).
"\",\"".
addslashes($emailaddress).
"\",\"".
addslashes($emailaddress).
"\",\"".
addslashes($firstname).
"\",\"".
addslashes($lastname).
"\",now(),".
"'a:4:{s:9:\"is_locked\";s:0:\"\";s:6:\"status\";a:1:{i:$product_id;i:1;}s:9:\"is_active\";i:1;s:17:\"signup_email_sent\";i:1;}'".
",1)");
$member_id = @mysql_insert_id();
if ($member_id<1) return 0;
mysql_query("INSERT INTO amember_payments (member_id,product_id,begin_date,expire_date,paysys_id,completed,time,tm_added,".
"tm_completed) ".
"values ($member_id,$product_id,now(),'2030-01-01','free',1,now(),now(),from_days".
"(to_days(now())+30))");
return $member_id;
}
?>
Notes:
1. To simplify login, new members are configured with their emailaddress as both the login and password. Make sure you ask users to change their password the first time they login.
2. Product_id is the unique amember_products ID identifying the product you would like to associate new members with
One of our long time Email Marketing clients finally made a decision to break out of frames.
They run a popular membership site, with well over 10,000 pages, a members-only back office, member websites and a blog. The site has been around since 1997.
Unfortunately, because the site runs inside frames, Google report only 3 pages are included in its index.
The site is invisible to Yahoo and MSN as well.
If you're not sure why frames are such a bad idea, both from a usability standpoint and search engine marketing, just Google frames are bad. Or read the Top Ten Mistakes in Web Design (hint: Using frames is #1)
The site design followed a typical frameset layout:
Left frame: Site navigation menu
Top frame: Site logo
Main frame: The document body
To prevent users who direct linked to an internal page from ending up in a "frameless" version of the site, a JavaScript was embedded on every page to detect if the page is running inside frames. If not, the JavaScript would redirect the user to the framed version of the page.
The challenge
How can our client cost effectively switch a 10,000 pages framed site, to no frames, without investing countless hours in redesigning the site internal linking structure from scratch?
How to avoid having to redesign graphics, while maintaining the existing look & feel?
What about the member's back office that relies heavily on cookies and session handling?
Our Suggested Solution
Luckily the existing site was including a header.cfm and footer.cfm files on all pages (Document Body main frame).
The header.cfm included the HTML meta tags, page title, stylesheet and a few Javascripts.
The footer.cfm included the site copyright message and some quick links.
To break out of frames, all it takes is include the content of the left frame (navigation menu) and top frame (site logo) as part of header.cfm
The new frameless version of the site, features single files, embedding the content of the left navigation menu and site logo as part of the header.cfm file:
We created a basic prototype of the new design and were able to run the site in a frameless mode. In one instance an IFrame had to be used to keep contents from a third-party site, appear encapsulated within our client's design.
The member's back office should continue to function normally without any drastic changes, as we are maintaining the same file names and domain structure.
The benefits of a frameless site are countless.
Fortunately, as long as your framed site includes header/footer files, which is common practice among all professional web design companies, breaking out of frames should be a snap.
Please comment and let me know your thoughts about frames and any other tips you can share with our readers.
View 4 Comment(s)
They run a popular membership site, with well over 10,000 pages, a members-only back office, member websites and a blog. The site has been around since 1997.
Unfortunately, because the site runs inside frames, Google report only 3 pages are included in its index.
The site is invisible to Yahoo and MSN as well.
If you're not sure why frames are such a bad idea, both from a usability standpoint and search engine marketing, just Google frames are bad. Or read the Top Ten Mistakes in Web Design (hint: Using frames is #1)
The site design followed a typical frameset layout:
Left frame: Site navigation menu
Top frame: Site logo
Main frame: The document body
<?php <frameset rows="100%" cols="150,*">
<frame name="side" src="left.html" scrolling="auto">
<frameset rows="70,*" frameborder="0" framespacing="0" border="0">
<frame name="topbar" src="top.html" scrolling="no">
<frame name="main" src="main.html" scrolling="auto">
</frameset>
</frameset> ?>
To prevent users who direct linked to an internal page from ending up in a "frameless" version of the site, a JavaScript was embedded on every page to detect if the page is running inside frames. If not, the JavaScript would redirect the user to the framed version of the page.
The challenge
How can our client cost effectively switch a 10,000 pages framed site, to no frames, without investing countless hours in redesigning the site internal linking structure from scratch?
How to avoid having to redesign graphics, while maintaining the existing look & feel?
What about the member's back office that relies heavily on cookies and session handling?
Our Suggested Solution
Luckily the existing site was including a header.cfm and footer.cfm files on all pages (Document Body main frame).
The header.cfm included the HTML meta tags, page title, stylesheet and a few Javascripts.
The footer.cfm included the site copyright message and some quick links.
To break out of frames, all it takes is include the content of the left frame (navigation menu) and top frame (site logo) as part of header.cfm
The new frameless version of the site, features single files, embedding the content of the left navigation menu and site logo as part of the header.cfm file:
We created a basic prototype of the new design and were able to run the site in a frameless mode. In one instance an IFrame had to be used to keep contents from a third-party site, appear encapsulated within our client's design.
The member's back office should continue to function normally without any drastic changes, as we are maintaining the same file names and domain structure.
The benefits of a frameless site are countless.
Fortunately, as long as your framed site includes header/footer files, which is common practice among all professional web design companies, breaking out of frames should be a snap.
Please comment and let me know your thoughts about frames and any other tips you can share with our readers.
View 4 Comment(s)
I've done a lot of research into improving the Google Quality Score for client PPC campaigns.
Better Quality Score means paying less for PPC clicks.
The top factors affecting your Quality Score are:
1. Account history
2. Average CTR (Click Through Rate)
3. Landing Page load time
4. Quality of incoming links pointing to landing page domain
5. Keywords/Description Meta tags and Page title
6. You need 6 Must-have pages (You need a Privacy Policy, Contact us and Terms & Conditions page)
7. Keyword density (Use https://adwords.google.com/select/KeywordToolExternal to make sure Google views your landing page as relevant for the target keyword)
By continually working on imporving your quality score, you'll be able to slash your PPC costs dramatically.
-
One of the easiest way to improve your landing page quality score, is to populate your page title and meta tags with the target keyword.
All you have to do is extract the keyword a user is searching for, from the referring URL and populate your page TITLE and meta tags with that keyword.
The code below does just that:
View 2 Comment(s)
Better Quality Score means paying less for PPC clicks.
The top factors affecting your Quality Score are:
1. Account history
2. Average CTR (Click Through Rate)
3. Landing Page load time
4. Quality of incoming links pointing to landing page domain
5. Keywords/Description Meta tags and Page title
6. You need 6 Must-have pages (You need a Privacy Policy, Contact us and Terms & Conditions page)
7. Keyword density (Use https://adwords.google.com/select/KeywordToolExternal to make sure Google views your landing page as relevant for the target keyword)
By continually working on imporving your quality score, you'll be able to slash your PPC costs dramatically.
-
One of the easiest way to improve your landing page quality score, is to populate your page title and meta tags with the target keyword.
All you have to do is extract the keyword a user is searching for, from the referring URL and populate your page TITLE and meta tags with that keyword.
The code below does just that:
<html>
<head>
<meta name="keywords" content="<?=$q?>">
<meta name="description" content="<?=$q?> - Widgets">
<title><?=$q?> - Widgets</title>
</head>
<body>
<h1><?=$q?></h1>
</body>
</html>
View 2 Comment(s)
| « Previous Posts |
About us | Contact us | Privacy | Terms & Conditions | Affiliates
Thursday, July 24th, 2008 Page generated in 0.437 seconds | |