The first step is to create a new folder under the web document tree (conventionally public_html) called wacs. Into this directory you need to copy all the components in the unpack_location/htmlbones directory and it's sub-directories, retaining the directory structure as found below htmlbones. There are a number of ways in which to achieve this and they vary enormously depending on your hosting provider, level of access at your hosting provider and equipment available to you locally.

If you are unsure of how to proceed, one of the easiest ways would be to create a zip file of these files (eg the htmlbones folder) on the PC where you unpacked the WACS software and upload that file. Hopefully your hosting provider provides the unzip command within your shell environment. If not, that's pretty much fair game for a support call, it's a pretty normal thing to need at a shell prompt.

Other techniques would include using a tar archive, the rsync command or placing all your configuration and enviroment files into a version control system like git or Subversion and using a text based client on the hosting provider to download them from your repository.

The second step is to check with the Perl Modules option in the control panel and make sure that DBI, DBD::MySQL and XML::Simple perl modules are available. If not, you may need to do one of three things: go through the process of importing them from CPAN, raise a support call with your hosting provider asking for them to be added or unpack them manually from the packages for the Linux distribution the web host provider is using (see notes in the section called “Final Notes For Web Hosting”).

The first step is to copy the Wacs Perl Modules into an appropriate place - our web hosting provider had already created a perl subdirectory of our account's home directory, so we used that. That probably makes sense even if it hasn't already been done for you as it wasn't on one of the other major web hosting providers we did an install for a consultancy customer on.

# cd unpack_location
# cp modules/wacs.pm ~/perl/Wacs.pm
# mkdir ~/perl/Wacs
# cp modules/wacsui.pm ~/perl/Wacs/WacsUI.pm
# cp modules/wacsstd.pm ~/perl/Wacs/WacsStd.pm
# cp modules/wacsid.pm ~/perl/Wacs/WacsId.pm
#

	Tip
	Note the change of case of the names; most command line ftp/sftp tools will allow you to specify a second name on a put command for the name of the file at the destination. Thus you can do: put wacs.pm Wacs.pm to do the name change as part of the transfer itself.

Additionally if you want to include support for the PHP dialect of the Wacs API, you will also need to copy some additional files. Before that however you will have to determine which version of PHP your hosting provider is using. The transition from Php 5.x to Php 7.x is quite recent - simply typing: php -v at the command line should give you the answer. These instructions are now targeted for the default Php which is version 7 on our hosting provider - if yours is still using Php version 5, substitute php5 for php in these instructions. You will need to do the following:

# cd wacs-php_unpack_location
# mkdir ~/php
# cp modules/wacs.php ~/php/wacs.php
# cp modules/wacsui.php ~/php/wacsui.php
# cp modules/XMLSimple.php ~/php/XMLSimple.php
#

The next step is setting up the cgi-bin directory - the first thing to do is to find out whether the hosting provider allows you to use one and if they have where the hosting provider has put it within your account's space. One major hosting company did not provide for a cgi-bin directory, instead requiring .pl extensions for each perl program. We built extensive support for doing this into the WACS 0.9.1 release and it now works reasonably effectively.

In the case of the provider we're using for PinkMetallic.com this is a sub-directory called cgi-bin under the public_html directory.

While the packaged versions of WACS have moved to creating their own wacs-cgi directory at the top level of the web server tree, we can only do that when we have control over the Apache (or other webserver) configuration. We can't assume that we will have this on a hosting provider, so we use a dedicated wacs sub-directory of the cgi-bin directory instead. We recommend putting the wacs scripts into a sub-directory of the cgi-bin directory when using a web hosting service to make it easier to manage upgrades and the like. Here's what to do with cgi-bin hosting providers:

# cd unpack_location
# cp index/wacs* ~/public_html/cgi-bin/wacs/
# cp models/wacs* ~/public_html/cgi-bin/wacs/
# cp presentation/wacs* ~/public_html/cgi-bin/wacs/
# cp retrieval/wacs* ~/public_html/cgi-bin/wacs/
# cp search/wacs* ~/public_html/cgi-bin/wacs/
# cp tag/wacs* ~/public_html/cgi-bin/wacs/
# cp security/wacslogin ~/public_html/cgi-bin/wacs/
# cp security/wacslogout ~/public_html/cgi-bin/wacs/
# cp security/wacspref ~/public_html/cgi-bin/wacs/
# cp manage/wacs* ~/public_html/cgi-bin/wacs/
# chmod 755 ~/public_html/cgi-bin/wacs/wacs*
#

For those who use .pl extensions, do the following:

# cd unpack_location
# mkdir ~/html/apps
# cp index/wacs* ~/html/apps/
# cp models/wacs* ~/html/apps/
# cp presentation/wacs* ~/html/apps/
# cp retrieval/wacs* ~/html/apps/
# cp search/wacs* ~/html/apps/
# cp tag/wacs* ~/html/apps/
# cp security/wacslogin ~/html/apps/
# cp security/wacslogout ~/html/apps/
# cp security/wacspref ~/html/apps/
# mkdir ~/html/admin
# cp manage/wacs* ~/html/admin/
# chmod 755 ~/html/apps/wacs*
# chmod 755 ~/html/admin/wacs*
# 

You will then need to rename each command to having a .pl extension - as in: mv wacsindex wacsindex.pl in both the apps and admin directories

As described above, the next step is to make copies of those wacs applications that are merely versions of existing applications with alternative default values. In most cases, this will be changing variables called either thumbsmode or vidmode as appropriate.

# cd ~/public_html/cgi-bin/wacs
# cp wacsmodelpage wacsmpthumbs
# editor wacsmpthumbs
# cp wacsmodelpage wacsmpmini
# editor wacsmpmini
# cp wacsmodelpage wacsmpfull
# editor wacsmpfull
# cp wacsimgcats wacsvidcats
# editor wacsvidcats
# cp wacsimgcats wacsphotcats
# editor wacsphotcats
# cp wacsimglist wacsvidlist
# editor wacsvidlist
# cp wacsimglist wacssetlist
# editor wacssetlist
# cp wacsnewsets wacsnewvideo
# editor wacsnewvideo
# cp wacsshow wacsvidshow
# editor wacsvidshow
# cp wacsindex wacspage
# editor wacspage
# cp wacsimgselect wacsvidselect
# editor wacsvidselect
#

One additional step we have to take within the web hosting environment is to add symbolic links within the cgi-bin directory back out to the ~/perl directory in order that our web applications can pick up the Wacs perl modules. This is done as follows:

# cd /home/yoursite/public_html/cgi-bin/wacs
# ln -s /home/yoursite/perl/Wacs.pm
# ln -s /home/yoursite/perl/WacsUI.pm
# ln -s /home/yoursite/perl/WacsStd.pm
# ln -s /home/yoursite/perl/WacsId.pm
#

Once again if you also want to support the WACS PHP API, you'll also need to make the appropriate links so that the php applications can find the Wacs PHP modules. Here the location depends on what skin or code you're using and will need to be present in each directory in which you have Wacs-PHP API based applications. Assuming you're going to be installing the Simple Skin, this will be in a directory called simple within your public_html web document tree. This can be done as follows:

# cd /home/yoursite/public_html/simple
# ln -s /home/yoursite/php/wacs.php
# ln -s /home/yoursite/php/wacsui.php
# ln -s /home/yoursite/php/XMLSimple.php
#

The next step is to install the Php applications and the simple skin if you intend to use them. This step is optional. There are two main sets of components and you can install either one or both of them. The first group are the apps - currently the dynamic model selector (modelsel.php) and matching set selector ( setsel.php). The second group is the sample website - the Simple skin - mentioned earlier. The apps come from the apps directory within the Wacs-PHP archive. You may need to make the necessary wacs directory within public_html if it does not already exist.

# cd /home/yoursite/public_html/wacs
# cp wacs-php_unpack_location/apps/modelsel* .
# cp wacs-php_unpack_location/apps/setsel* .
# cp wacs-php_unpack_location/skins/simple/*.php .
# cd styles
# cp wacs-php_unpack_location/skins/simple/styles/* .
#

The final aspect of file installation that needs to be covered is to provide the necessary jQuery library used by the two dynamic php apps, modelsel and setsel. There are a number of approaches to this but basically a suitable version of the file jquery/jquery.min.js needs to be available. The URL that the apps will ask for is defined in the server section of the Wacs configuration file using the variable jqueryurl. Basically you can set this to what you like, using the publicly hosted versions at Google, installing this through your administration panel on your hosting provider or simply by downloading it direct from jquery.org and placing it within the document tree of your site (ie in public_html). You will need to adjust the entry in the wacs.d/wacs.cfg file, server section accordingly. We are currently using JQuery major version 3 with Wacs-PHP but we're not very demanding on what we need; if your hosting provider is offering an older or newer version, it's probably not an issue.

Note

Please be aware that earlier versions of Wacs prior to 1.x used an alternative library for dynamic exchanges (aka AJAX) called XAJAX. We do still include a version of this in the Wacs distributions for anyone who developed code using it for use with Wacs. None of the code we supply needs it anymore and it will be removed at some point in the future. If you are bringing across existing custom applications that use it, you will also need to unpack it from the wacs-php archive.

This is one area where the procedure for a Web Hosting Site is significantly more complex than that for a conventional Wacs install as practically all of the entries related to database and file system locations (fsloc) will need tuning based upon actual layout of the account on the web hosting site.

The first step is to create a suitable sub-directory for the wacs configuration files, ideally in the top level of your file space. If at all possible DO NOT put it in the web space directory as it contains passwords and other configuration items which you do not want everyone to be able to access. Next you want to find out the full path name of your top level directory, for which you use the pwd to the Linux/Unix shell.

# pwd
/home/yoursite
#

Your wacs configuration files will therefore live in /home/yoursite/wacs.d instead of the normal location of /etc/wacs.d. To make this change we have to go into the Wacs.pm perl module in the perl sub-directory and make the appropriate change. We could avoid this if the web hosting provider would allow us to establish the WACS_CONFIG environment variable in the appropriate virtual server configuration section in the apache web server. Our hosting provider would not do this for us so we have to work around that by modifying the default value in the Wacs.pm perl module itself. This is a little unfortunate in that it'll mean we have to modify this module each and every time there is a Wacs code update that affects it.

Here's the appropriate change you need to make - what we've done here is copy the line setting the existing value called default_location1 and commented out the original version with a hash (# ) symbol at the start of the line. We've then edited the copy to have the new location on our web hosting provider's site there as the first default location:

# Assumptions
my $fssep = '/';

# Where to find the WACS configuration
#my $default_location1="/etc/wacs.d";
my $default_location1="/home/yoursite/wacs.d";
my $default_location2="/usr/local/etc/wacs.d";
my $default_location3="/opt/wacs/etc/wacs.d";
my $default_specifier="WACS_CONFIG";

	Note
	If you're also planning to use the PHP version of the Wacs API you will need to make identical changes to the wacs.php file provided with that.

The next step is to copy into this new wacs.d directory a sample wacs.cfg and wacs.acl file. We've provided a sample pair that will hopefully be a good starting point in the conf/WebHost sub-directory of the wacs source distribution. Please do make sure that you manually create at least each toplevel directory under your account's home area - ie run, cache, etc.

login as the database user just created and run the table create SQL script from the creation directory of the wacs distribution. These scripts are called by a single creation script, the one for MySQL is called create_mysql.sql and that is sometimes the only option available on web hosting sites. Those sites that do support PostgreSQL should find that the create_postgres.sql script will work as it should in these environments. At this point we haven't tested this option so please let us know if you try it what issues you encounter. One hosting provider still had the older MySQL 5.0 version as their offering and we had only one minor problem with it (see the section called “Final Notes For Web Hosting”).

To run this on MySQL 5.1 using the account created in the step above, you would do the following (the only difference for a web hosting service is that you probably have a yoursite_ prefix on the user and database names):

% cd unpack_location/creation
% mysql --user=wacs --password=wacs wacs < create_mysql.sql
WACS Database Table Creation Script for MySQL
Commencing Table Creation:
  1. Photographer
  2. Vendor
  3. Sets
  4. Models
  5. Assoc
  6. Idmap
  7. Download
  8. Tag
  9. Conn
 10. Keyword
 11. User
 12. Attrib
 13. Notes
Tables Created - Committing Changes
Completed.
%

# cd unpack_location/populate
# ./wacspop vendors.xml
Inserting Entries For Site: ATKP
Inserting Entries For Site: AMK
Inserting Entries For Site: ATE
Inserting Entries For Site: SE
#

# cd unpack_location/populate
# ./wacspop keywords.xml
[...]
#

# cd unpack_location/populate
# ./wacspop photographers.xml
[...]
#

# cd unpack_location/populate
# ./wacspop attrib.xml
[...]
#