Document version: $Id$
This document describes MiniVend 3.12 and earlier.
MiniVend is a freely-redistributable electronic catalog, otherwise known as a shopping cart. It serves any number of catalogs via the World Wide Web, allowing users to select items for placement on their shopping list, or cart, and then buy them by filling out an order form. Since MiniVend supports Secure Sockets Layer (SSL), the customer can securely put their credit card number in the form if you have an HTTP server that supports SSL.
MiniVend supports a host of features -- a complete list is available at its web home page:
http://www.minivend.com/minivend/
MiniVend is written and maintained by Mike Heins, but much credit goes to Andrew Wilcox, who originated Vend and created many of the underlying algorithms.
MiniVend is freely redistributable under the GNU General Public License, a copy of which should come with every MiniVend package. Basically this means that you can use it for commercial or non-commercial purposes for free, but you you have certain responsibilities if you modify and/or redistribute it. See the GNU GPL for more information.
You simply download it from:
http://www.minivend.com/minivend/download.html
It also sometimes appears in the Comprehensive Perl Archive Network (CPAN) library. There are over 40 CPAN sites worldwide. The master site is ftp.funet.fi, with mirror sites located on every continent except Antarctica. MiniVend is available in the directory:
CPAN/authors/id/MIKEH
where CPAN is the base URL for any CPAN site. A list of CPAN locations is always available at
http://www.perl.com/CPAN/
As to cost, MiniVend is free within the confines of the GNU General Public License. Basically, any individual or company can use MiniVend free of charge -- you have certain responsibilities if you modify your copy then redistribute it.
MiniVend is a complex system requiring the services of other complex pieces of hardware and software. While it can be very easy to install, you must look at the ongoing environment as well as just the initial installation.
perl -MCPAN -e 'install Bundle::Minivend'
and it should install all of the modules necessary except the DBM/DBI ones.
These modules are strongly recommended:
MD5
MIME::Base64
URI::URL
Data::Dumper (comes with Perl 5.005)
GDBM or DB_File (comes with most i386 Perls)
These are definitely recommended:
Storable
SQL::Statement
Bundle::LWP (contains MIME::Base64 and URI::URL)
These are nice to have but are not essential:
Business::UPS (comes with MiniVend)
Term::ReadLine::Perl
Term::ReadKey
You will need the DBI module if using SQL, along with the appropriate DBD module for your database.
The recommended packages for ActiveState Perl for Windows are:
MD5
MIME::Base64
LWP
The MiniVend setup program will attempt to use ppm.pl, the ActivePerl package manager, to install them at installation time.
fork() model which works so well with MiniVend.
A catalog designed on a Windows machine should just move over to a UNIX machine with no changes, so Windows might be a suitable development environment.
If you are located on a machine with many hundreds of domains, as sometimes happens with low-cost hosting operations, you can expect some problems. It is difficult to maintain a stable environment with that many users.
MiniVend will run about as well as the platform beneath it. It routinely runs for months non-stop in a stable environment.
MiniVend is not guaranteed to be supported in any fashion other than to make full source code of the current version available. However, the author is interested in making MiniVend as reliable and trouble-free as possible. Forward bug reports, questions and comments to the mail list, minivend-users@minivend.com.
MiniVend is powerful and correspondingly complex. If you are looking to ``point-and-click'' your way to a catalog, you probably should look elsewhere.
Do understand that any problems answered in this FAQ or the documentation may be ignored if you don't:
The official MiniVend web site is:
http://www.minivend.com/minivend/
The latest version of the software, this FAQ, and the documentation, are available there. Your problem may not be unique -- check the site first.
The most common problem on
UNIX is receiving the ``We're sorry, the MiniVend server is unavailable...'' message. This almost always means that permissions are not properly set up, or that the
VLINK program is not setuid (this means that a program runs as a possibly different user
ID, and is enabled with the
UNIX command ``chmod u+s <
file>''). Try temporarily changing the permission of the
MINIVEND_ROOT/etc/socket file to be read/write to all groups (chmod 666
etc/socket). If MiniVend then works you will have to make sure the user that the
VLINK program runs as matches the user who is running
the MiniVend daemon. It is usual to create a special mvend or minivend user to run the daemon and the link program. This means the directory listing for your
CGI-BIN should be something like:
-rwsr-xr-x 1 minivend users 6312 Dec 30 11:39 cgi-bin/simple
and for the socket file it should be:
srw------- 1 minivend users 0 Dec 30 11:41 etc/socket
See the next section for troubles with running MiniVend on ISP sites.
The most common problem on Windows is receiving ``Bad command or file name'' when trying to run the self-extracting ZIP installation. This means that Perl 5.004 is not installed on your machine or is not in your path. You must properly install Perl 5.004 before extracting.
Beyond that, if you are unable to get MiniVend installed you should check
to see if you can run any
CGI program from the path it is trying to use. The
next most common problem is the user giving the wrong information to makecat.
MiniVend is intended to work on Perl Version 5.004 and higher, but the author does not have the resources (read time) to regression test all versions with the different versions of Perl. MiniVend will definitely be tested with the last major release of Perl at the time of package release. As of this writing, MiniVend's version is 3.12 and Perl's latest version is 5.005_02.
Please understand that the first remedy in the case of unknown problems will be to upgrade Perl to the latest version.
First, check the the official MiniVend web site for information:
http://www.minivend.com/minivend/
If you are unable to get MiniVend installed, it is almost always a problem with the Perl installation. Common problems include:
There are many more possible problems. See the README file for other OS-specific problems.
Second, double check that you have done the following things:
tlink over the
cgi-bin/simple or simple.cgi program?
If you have a problem you are not able to correct, and you have taken all of those steps, you can send email to the MiniVend users list:
minivend-users@minivend.com
Please include your operating system name and version, your Perl version, the DBM library in use, and the contents of ALL error logs.
Please see this if you don't get an answer:
http://www.minivend.com/minivend/the_authors_life.txt
MiniVend is an ambitious and complex program, and is not presented as being easy to use, easy to install, or bug-free. The configuration script was done to try and make a very painful process only slightly painful. Some people install in one pass. Others never make it. Determined and thoughtful users almost always make MiniVend work.
The great majority of ISPs provide some CGI service, and more and more run systems that are compatible with MiniVend. The catalog configurator for MiniVend is designed to figure out many ISP directory setups.
Almost any Internet Service Provider (ISP) system should be able to run MiniVend, but some cannot (or will not) run MiniVend at all. On top of that, many times ISP personnel are too busy to help, won't help, or don't know enough to help. Some are secretive about details of the setup of their systems.
MiniVend does require a stable platform underneath it. Many ISP servers are heavily loaded (especially low-cost ones). If you run on a server which is constantly running out of memory and file descriptors, you will not be happy with your results with MiniVend.
Virtual servers that don't provide shell access are not really usable for MiniVend without direct support from the ISP -- unless you are a CGI/Perl wizard who can figure out how to do it. 8-) It can be done (with a good deal of difficulty) on some virtual servers.
Iserver.com and others who use an chroot HTTP daemon for each user will require some source-code twiddling to get the paths for vlink right -- the catalog configurator will not do the trick. See the mail list archives for the hack.
MiniVend does require a lot of memory, and it does run as a daemon. You will find that that vexes a fair number of ISPs. I have found it difficult to provide power and speed without using memory, so it will have to stay that way for the time being.
All in all, you can have a fair amount of confidence that your ISP can run MiniVend. Or, you can get one who will. 8-)
MiniVend is now distributed in a self-extracting zip. If you don't want to install it there, use your
ZIP program to extract to a directory and then run
setup.bat or configure.bat.
The
ZIP file is identical to the tar file except for the
presence of two files, cygwin.dll and setup.bat.
If you are planning on installing it on UNIX, it really should be untarred on a UNIX machine. Though some Windows ZIP clients will handle the file type, it is best if you just get the README file from the same place you got the distribution and read that.
On the UNIX machine, typically your company server or ISP server, you need to do:
gzip -dc minivend-X.XX.tar.gz | tar xvf -
If you have transferred the file to your Wintel machine before then transferring it to the ISP, make sure you have done all transfers in BINARY mode. You will have weird problems if you have made one or more of the transfers in ASCII mode.
Vend was written by Andrew Wilcox in the early part of 1995, and the first released (beta) version was 0.2. Vend 0.2 is the parent of MiniVend, and the first version of MiniVend (called Vend 0.2m7) was totally based on that. It added searching and DBM catalog storage. Subsequent versions took parts from Vend 0.3, especially the VLINK and Server.pm modules, which were adapted to run with MiniVend.
The first release of MiniVend (1.0) was on February 23, 1996, making it nearly three years old. A veritable eon in web time!
Other portions of Vend, notably the database interface from 0.3, were adopted, but there are distinct differences between MiniVend and Vend.
Andrew is no longer working on Vend, and all questions and comments regarding both Vend and MiniVend should be directed to Mike Heins, <mikeh@minivend.com>
Usually it is for one of the following reasons:
Maybe. It has been downloaded over 100,000 times (availability at 50+ FTP sites means it is unknown how many more times than that) with no reported system security problems. It uses the Perl Safe.pm module for user-embedded Perl subroutines and conditionals to make use of those pretty carefree.
However, there are definite potential problems with credit card number security that can be avoided:
If you don't use the CreditCardAuto capability for encrypting credit card numbers, or the supplied CyberCash interface, then there will be unencrypted credit card numbers present in your session database files.
If your system is the target of a break in, then these numbers would be available to any user ID that can read the session files.
This is the reason MiniVend defaults to read/write permission for the MiniVend user only.
The same things apply for orders sent via email. If it is not encrypted with PGP, then it is at risk.
The default demos also store the orders in the file etc/tracking.asc, so you should check there as well if you want to scrub existing credit card numbers on disk.
If you are using INET mode, and the transmission is going via the network to another machine (i.e. not localhost), then you should be possibly concerned about which wires your SSL-encrypted data is traveling over. You should be behind a firewall, firewall router, or at least some sort of spoofing-protected filter.
The bottom line is that security needs to be your concern. MiniVend tries to warn you and provide means for protecting customer data, but it can't stop you from doing all unwise things. The author stands behind the license for MiniVend and disclaims all responsibility.
None, really, though you can embed many MiniVend tags inside of regular HTML with things like:
<A HREF="[href minivend_page]">Link</A>
<SCRIPT LANGUAGE=MV MV="set Action">
mv_todo=return
mv_nextpage=your_page
</SCRIPT>
In most cases you will have to edit MiniVend pages by hand.
(MiniVend 3.09 is the first version to allow tags to be embedded within regular HTML.)
(This is the author, Mike Heins, speaking.)
I am interested in creating a better MiniVend. However, it has become pretty popular and you should not expect individual support.
What I will typically do:
All of these are things I try to do. There is no commitment -- check your license for MiniVend. All are done on a time-available basis. If you don't include all relevant information I will probably ignore the question. I answer on the mailing list so that information can get to more people and be archived for posterity.
What I will not do:
If you cannot work with MiniVend without more help, you should engage a consultant to help with integration and administration. The ideal consultant will have a complete understanding of web servers, HTML, databases, and Perl.
The author is sometimes available for consulting on MiniVend, and offers a seminar on using and employing MiniVend.
If you cannot find a consultant, you might post to the mail list and solicit help. Several competent consultants frequent the list and may respond.
MiniVend is a full-featured shopping cart with high-end power. It can and does maintain databases of hundreds of thousands of items or more, and is frequently used in catalogs with hundreds or many thousands of items.
MiniVend is a database-based shopping cart, and has a complex implementation and a fairly steep learning curve. If all you are ever going to catalog is just a few items, and/or the items will not frequently change, MiniVend may be overkill for your needs. It may make more sense to go with a simpler cart that embeds the product information in the page and does not require database setup.
Things that might call for the use of MiniVend:
When Minivend might not be the right choice and you might want to use another free cart
When to consider a commercial product
When comparing MiniVend to commercial products, the comparison is better drawn to the higher end ones costing thousands of dollars rather than the low end ones costing hundreds of dollars.
Subjectively, people have both good and bad experiences with MiniVend.
After investing tens of thousands of dollars and almost
a year of effort in commercial software, we switched
to MiniVend and were operational within weeks.
-- large corporation
MiniVend is too difficult for the user to configure. There
are too many things that must be gotten just so.
-- Small internet service provider
I really like the new site, its laid out well and the
documentation is so good I've decided to use it even though
I'm not a programmer.
-- happy prospective user
Your documentation is awful.
-- not-so-happy prospective user
Your documentation is some of the best and most comprehensive
we have seen for a freeware program.
-- happy user
And the your pages don't have the right information in
them and that's MY FAULT? How about the fact that your
configure script acts differently every time it gets run?
-- not-so-happy user
(Obviously, mileage varies with the user. Thankfully, the happy ones *seem* to outnumber the unhappy ones by 10 to 1 or more...)
Despite being free, MiniVend will require an investment -- either your time or the money to engage a consultant skilled in the web and in databases. If given its due, MiniVend can provide power that no other free shopping cart has.
This means Perl is not in your PATH or is not installed.
You can use a ZIP program to extract the archive to a temporary directory and then either:
If you still have problems, it probably means Perl is not installed properly. You need the either the ActiveState 5.005 version, or the 5.004 version, variously known as the Gurusamy Sarathy, core, or standard version. See this page for pointers to the latest Perl:
http://www.perl.com/pace/pub/perldocs/latest.html
See the Perl distribution for details on how to install it, the MiniVend README-win.txt file for pointers to exact URLs, or visit
http://www.perl.com
for more information.
NOTE: MiniVend will not work with the ActiveState version 5.003 build 3xx distributed with the NT resource kit.
There is a bug in MiniVend 3.06 which fails to account for Windows not being able to have a colon (:) in a filename.
This is fixed in MiniVend 3.07 and above.
This is caused by an intermittent failure in the Win32::Shortcut module (or my application of it). In any case, unzip the file, and run ``setup''. If/when it fails with this error, create a file named ``Start MiniVend Server.pif'' and rerun the installation.
This problem should be eliminated in MiniVend 3.12.
Most MiniVend configuration and setup problems are due to one of:
RedHat Linux 5.0 distributed a broken Perl; update it if you have an RPM earlier than February 1998.
If your web server is Apache or
NCSA, Minivend will try and parse its
httpd.conf file to help you along, but many ISPs don't allow users to read these and
it may fail.
(None of this is valid for Windows. Use the precompiled tlink.exe.)
The latest version of vlink.c and tlink.c have been compiled on the following systems:
BSD2.0 (Pentium/x86)
FreeBSD 2.1
SunOS 4.1.4
Solaris 2.4 (Sun compiler)
Solaris 2.5 (GCC, but not all versions)
Linux 1.2.13
Linux 2.0.x
IRIX 5.3
Digital Unix (OSF/Alpha)
AIX 4.1
SCO OpenServer 5.x
Some problems may occur. In general, you can ignore warnings about pointers.
Make sure that you have run the configure program in the src directory. If you used MiniVend's configuration, and selected the default of compiling those programs, the configuration was run, and all of the proper libraries should be used.
You can compile manually with the proper settings with this series of commands:
cd src
./configure
perl -e 'do "syscfg"; system ("$CC $CFLAGS $DEFS $LIBS -o tlink tlink.c")'
perl -e 'do "syscfg"; system ("$CC $CFLAGS $DEFS $LIBS -o vlink vlink.c")'
There is also a ``compile.pl'' script which will compile with the current settings.
If you cannot compile, try using the tlink.pl script which should work on most any system.
This is the most common problem on
UNIX systems. It almost always means that permissions are not properly set up, or that the
VLINK program is not setuid. Try temporarily changing the permission of the MINIVEND_ROOT/etc/socket file to be read/write to all groups (
chmod 666 etc/socket). This must be done after the server is started, as MiniVend deletes and recreates the socket every time it starts. If MiniVend then works you will have to make sure the user that the
VLINK program runs as matches the user who is running the MiniVend daemon.
<
HR>
It is not recommended that you install the MiniVend software
as root. If you are setting MiniVend up for the entire machine, and not just as a
virtual host user, it is usual to create a special mvend or minivend user to run the daemon and the link program. This means the directory listing for your
CGI-BIN should be something like:
-rwsr-xr-x 1 minivend users 6312 Dec 30 11:39 cgi-bin/simple
and for the socket file it should be:
srw------- 1 minivend users 0 Dec 30 11:41 etc/socket
Once you have set up the software, you can easily install catalogs as root as long as your umask is set to 2 or 22.
(The following assumes you have made the MiniVend software owned and run by
the special user mvend and that each user has a MiniVend catalogs directory /home/user/catalogs).
The following policies should be automatically offered when installing MiniVend 3.06 or higher.
The best way to set permissions on a multi-user system is to make all files
group readable and writable (660 or 664 mode). If you have a system setup
that places each user in their own group, then make
mvend a member of each user's group and set ownership and permissions with:
find /home/user/catalogs -print | xargs chown user find /home/user/catalogs -print | xargs chgrp user find /home/user/catalogs -print | xargs chmod g+rw
For best results, make the user's default umask be 2 so that they will by default create files that have the proper permissions.
If you have all users in the same group, the above is not secure. You
should put mvend in a group of which no user is a member (perhaps mvend would be a good
choice) and then make all files owned by the group mvend and all
directories be set to mode 2775:
find /home/user/catalogs -print | xargs chown user find /home/user/catalogs -print | xargs chgrp mvend find /home/user/catalogs -print | xargs chmod g+rw find /home/user/catalogs -type d -print | xargs chmod g+s
This will make files default to the proper group when created (on most UNIX versions, anyway). <HR>
If you are on a virtual hosting system, the procedure varies. Making the program setuid should work for most systems -- if your setup uses
CGI-WRAP or another setuid scheme it should still work
OK, though you may have to
unset the setuid bit with chmod u-s cgi-bin/simple or the like. If you have a non-standard
CGI setup, as some virtual host systems do, you will need to know something about
UNIX and the web -- or engage a consultant -- to properly set the paths up. Usually switching to
TLINK/INET mode is the easiest thing to do, though with
Iserver and a few others it may take more than that.
<HR>
If you used the makecat program to build the catalog, it should warn you if it was not able to make
the link program setuid. To set the program (in the file cgi-bin/simple in this example) to be setuid, you use the command:
chmod u+s cgi-bin/simple
Please understand that the first remedy in the case of unknown problems will be to upgrade Perl to the latest version.
This indicates that the link CGI is not communicating with the MiniVend server.
IMPORTANT NOTE: The server should always be started by the same user ID which owns the suid vlink program. (This does not apply to TLINK/INET mode.)
The server must be running, first of all. If you didn't start it, you can do so by going to the MiniVend home directory and typing:
bin/start
You can check to see if your server is running by typing:
Linux, SunOS, BSD: ps -ax | grep minivend
Most other systems: ps -elf | grep minivend
Note: Solaris and
IRIX truncate the string, and doesn't allow setting of
the $0 parameter. You may have to grep for 'perl' instead.
If the server is not running, it may have failed due to another process occupying the TCP socket 7786. If using VLINK, you may start MiniVend with 'start -u', which will not monitor the internet-domain socket.
If VLINK is not communicating with the server, there are a number of possible reasons. First, if you are trying to run MiniVend on an ISP, go to the section about ISP problems -- it is probably one of those. If you are running MiniVend on a single machine, it is probably one of:
1. Permissions problems
2. MiniVend on NFS-mounted file system
Permissions are easy. If you for some reason can't run VLINK as an SUID program (SUID to your user ID, not to root), then you will need to make permissions more permissive. See the MiniVend documentation for how to use the ReadPermission and WritePermission directives to make the session files and sockets 'group' or 'world' readable and writable. If you can make your UID, or the one you have chosen to own MiniVend, the same group as your HTTP user, then you can make the files group read-write. If you can't, you will have to set the dreaded 'world' permissions.
If you are running MiniVend on an NFS-mounted file system it cannot run in server mode, because UNIX-domain sockets don't work on NFS. You will need to change to static mode from server mode, or better yet, put MiniVend on a file system that is directly mounted.
As of MiniVend 2.03, you can use MiniVend in INET mode along with the tlink.c program to allow running across NFS boundaries. If you have not changed the configured defaults, and still it will not communicate, you should try setting the LINK_HOST and LINK_PORT directives in tlink.c and recompiling. <hr>
This means your Perl is not properly installed, or that MiniVend is not using the proper Perl binary. On UNIX, try reinstalling MiniVend and using the standard Perl installation sequence:
/complete/path/to/proper/perl Makefile.PL
make
make test
make install
Otherwise, contact your system administrator.
This is a feeble attempt at humor. Check out the Quantity Pricing feature of MiniVend. Try looking at:
http://www.minivend.com/cgi-bin/simple/quantity?;00-0011
Your Perl is not properly installed. Someone has put a Perl up on your system, then either moved or removed the library directory.
Contact your system administrator and ask them to re-install Perl.
No. MiniVend will not run on a Macintosh running System 7 or other ``Finder'' operating system. If some technically-oriented user would port it, or someone will give MiniVend's author a PowerMac, then it might. 8-)
MiniVend's *files* can be manipulated by any computer. As long as uploads/downloads of database source, pages, and configuration files are done in ASCII mode, there is no reason you can't edit them on your Mac. And with MySQL or other ODBC databases on your UNIX-based ISP, you can even directly interface to the database you use with MiniVend -- provided you have the scarce ODBC middleware needed for the Mac. But you must run it on a UNIX (or maybe soon on a Win95/NT machine).
MiniVend has been known to run on MkLinux and Linux for the PowerPC.
This is usually due to the HostnameLookups (Stronghold/Apache parameter) not matching for the two servers, secure and non-secure.
If it still does not work, then try changing some of the appropriate configuration parameters in minivend.cfg:
DomainTail No
IpHead Yes
The above setting will typically make MiniVend work when it is possible to work.
WideOpen Yes
This completely disables IP checking.
If this happens when you run the MiniVend test or server, it is always a Perl that has a problem. Not sometimes, always.
A proper Perl should never have a segmentation violation, period. And it should not dump core (unless you passed it a -u option somehow).
You will need to either update Perl or report the bug to the proper personnel. Depending on your situation and technical ability, this may be your system admin, ISP, or the Perl porters.
This is a Perl which does not have the right Perl library installed. It usually results from a naive system administrator who thinks they can bypass the 'make install' for Perl and just copy the Perl binary.
In any case, it has nothing to do with MiniVend when you are running on UNIX. MiniVend does not include any compiled libraries.
This is just a warning caused by a bug in MiniVend 3.02 and is benign.
To eliminate the warning, go to the catalog directory and do:
touch pages/.static
This is a defective Perl distributed by RedHat. The problem is that they don't take GLIBC into account. It will pass make test 100%, but strftime dumps core on a segfault.
You can either update your Perl RPM, or build Perl 5.005 or higher on your machine. Either should solve the problem.
Great strides have been made since MiniVend's early days. The great majority of ISPs provide some CGI service, and more and more run systems that are compatible with MiniVend. The new catalog configurator for MiniVend makes setup much easier.
A word of warning -- if you chose your ISP mostly on price, you can expect problems. There is no such thing as a free lunch; the low-cost providers typically have heavily-loaded machines and many domains. The more domains and the more load the unhappier you will be with MiniVend. MiniVend works best on a fast machine with plenty of memory.
A few Internet Service Provider (ISP) systems still have difficulty with one or the other aspect of running MiniVend. A few cannot (or will not) run MiniVend at all. On top of that, many times ISP personnel are too busy to help, won't help, or don't know enough to help. Some are secretive about details of the setup of their systems.
All in all, you can have a fair amount of confidence that your ISP can run MiniVend. Or, you can get one who will. 8-)
This used to mean that you were totally out of luck. You probably still are, but it is at least possible to run MiniVend on a virtual server such as HWY.NET.
You should be able to use the tlink.pl program and INET mode to start using MiniVend -- with quite a bit of work. You will need to hand-edit all of the configuration files, and use tlink.pl with the appropriate settings. Long term, you should put a compiled tlink in place.
You will also have to start the MiniVend daemon via a CGI program that you write.
Bottom line: don't try this unless most people call you a wizard. 8-)
The MiniVend web site has pointers to ISPs who happily host MiniVend.
Since VLINK needs certain values set in the source before compilation, a pre-compiled version will not work. It is recommended that you get the latest version of MiniVend and run in INET mode along with the tlink.pl Perl-based link program.
A pre-compiled tlink.c might also work for you if you can use the defaults of 'localhost' and port 7786.
MiniVend 3.12 requires Perl 5.004 or higher. Perl 5.004_04 or higher is strongly recommended.
MiniVend earlier than 3.06 can run on Perl 5.003, but don't expect any support from the mail list.
The below all assume you were able to start the MiniVend server.
This could be almost anything, but with a properly configured MiniVend it is almost undoubtedly due to your CGI-BIN and/or your MiniVend directory being located on a different filesystem than the actual machine that is executing the program. VLINK uses UNIX-domain sockets, which don't work on NFS-mounted filesystems.
Iserver.com and other systems which use chroot HTTP servers require quite a bit of extra configuration to get going.
If you have not been careful to set permissions properly when running in VLINK/UNIX mode, the link CGI will not be able to communicate with the MiniVend server. Please read the documentation, which covers this in detail.
As of MiniVend 2.03, you can run in INET mode with the tlink link program to prevent those problems.
This usually means that your HTTP server ran out of resources during the execution of the link program. It couldn't create more sockets, is unable to create a process, or can't open any more files.
This happens especially in frames catalogs, when MiniVend is sending more than one page simultaneously. And even more especially on FreeBSD and BSDI, which are distributed with the kernel parameters SOMAXCONN and CHILD_MAX set to levels unsuitable for serving the web.
Go to
http://www.dejanews.com
and try searching on CHILD_MAX -- this should give you plenty of pointers on how to set those parameters properly.
MiniVend is unlikely to work on Windows
NT ISPs in the near future. If you have a dedicated
NT machine, there is a version of MiniVend for Windows
NT. It may work well for you, but there are differences in operation from the
UNIX version (mostly due to NT's lack of fork() or and lack of threading support in Perl).
Many ISPs don't allow your user ID to run a program unless it is logged in! The moment a watchdog program notices a daemon running with a non-logged-in UID, it terminates the program. Or it terminates programs that haven't been active for XX minutes. Contact your ISP about this -- they may be able to do something for you.
There are a few things that seem to escape some users in the documentation. This is no doubt due to the author's closeness and familiarity with the concepts of MiniVend.
This section attempts to explain some of these basic issues.
MiniVend is not just a script. It is a combination of many programs, Perl modules, and links to other subsystems such as SQL databases, CyberCash, PGP, and the Glimpse search engine.
It is so big because it is more than just a shopping cart -- it is a complete database access and retrieval application. It uses a lot of memory because the author got a case of feeping creaturitis and added too many features while attempting to maintain backward compatibility with older catalogs.
This means that MiniVend is probably not a good choice for someone who is going to offer only a few products. It is optimized for catalogs of more than a hundred items -- catalogs that expect to change and grow over time. It is suitable for very large catalogs.
A daemon is a program that always is running in the background on the system, initialized and waiting for something to do. MiniVend runs as a daemon in the normal course of events.
Other programs that you may be familiar with that run as daemons in most cases:
MiniVend takes an appreciable amount of time to compile and load except on the fastest systems. It has many configuration options, and can serve hundreds of catalogs. If it were to be loaded every time a user accessed it, it would be unusable.
The daemon approach allows a rich set of features to be accessed fast. The actual CGI program (vlink or tlink) is a small program written in C -- it communicates with the minivend daemon.
One of the side effects of this is that when you change a configuration file, you must tell MiniVend. You do this either by restarting the server, or better yet, using the reconfig script to reconfigure an individual catalog.
MiniVend pages are not kept in normal HTML space. Look in the catalog subdirectory pages.
The pages are always filtered through the MiniVend daemon before being delivered.
MiniVend is a CGI program, and if you tried to use relative image paths you would end up with IMG tags like
<IMG SRC="/cgi-bin/simple/../whatever.jpg">
Not what you want. So MiniVend by default uses an
ImageDir for a prefix. In the demo that would be /simple/images/, so image specs that have no absolute path information are prefixed with
that.
In your MiniVend page, this tag
<IMG SRC="ordernow.gif">
will become
<IMG SRC="/simple/images/ordernow.gif">
and this:
<IMG SRC="items/00-0011.jpg">
will become
<IMG SRC="/simple/images/items/00-0011.jpg">
Absolute image paths are not affected, so if you reference an image at /other/images/whatever.gif, it will not be touched.
No effort needed -- MiniVend does this automatically.
Every user session that is started by MiniVend automatically creates a variable set for the user. As long as the user session is maintained, and does not expire, any variables you set on a form will be ``remembered'' in future sessions.
Don't use the prefix mv_ for your own variables -- MiniVend treats these specially and they may not behave as you wish. Use the mv_ variables only as they are documented.
Also, because you can set so many variables, MiniVend does not unset variables it does not find on the current form. That means you can't expect a checkbox to become unchecked unless you explicitly reset it.
In general, you don't need to quote the following tags which are interpreted first within a list:
[item-code] [item-data ...] [item-field ...] etc.
[loop-code] [loop-data ...] [loop-field ...] etc.
[sql-code] [sql-data ...] [sql-field ...] etc.
This is because they are interpreted as a part of the surrounding [loop], [item-list], [search-list],
[sql list], or [tag each table] constructs.
So this will work:
[item-list]
[page [item-field url]]detailed info[/page] on [item-description]
[/item-list]
This will not work:
[page [value mypage]]
The [value ...] tag is not interpolated before page, and the parser will not know to do so. It needs to be instead:
[page href="[value mypage]"]
Clear as mud, right? Well, at least if you quote them all you can't go wrong. 8-)
IMPORTANT NOTE: The above only applies to New style tags. The old MiniVend 1.x/2.x parser interpolates tags in a highly ordered fashion and tags are rarely/never quoted. It is no longer recommended that you use the old parser. If you have constructs which work under the old parser and that you want to retain, surround them with a [compat]... the tags ...[/compat] tag pair to send them to the old parser.
Yes, but you probably won't want to in the long run.
MiniVend is designed to build pages based on templates, from a database. If all you want is a shopping cart, you probably should use a simpler program.
It is not difficult to convert existing static pages to MiniVend, but maintaining them can be a nightmare.
MiniVend is quite powerful, but also quite complex. There are many new possibilities opened up with its conditional HTML, but also many pitfalls.
Read the documentation thoroughly, then inspect the sample
and simple demo pages for help. Pay particular attention to:
browse*.html
flypage.html
results.html
ord/basket.html
ord/checkout.html
These pages use many of the powerful features of MiniVend, and studying them will be instructive.
Yes. MiniVend supports multiple independent catalogs. There are users who run more than 500 catalogs on a single machine. The capacity is usually a function of how busy the catalogs are and how much memory and processor speed your system has.
Use the standard facility on your operating system. For BSD style systems, the file is usually called rc.local (in the /etc directory).
On SVR4 systems, it is quite a bit more complex -- look for the /etc/rc.d directory and see what other programs do. Often the file is called S99startup or something similar.
IMPORTANT NOTE: MiniVend must not run as root, which is the user that the startup file executes as.
The technique to start up depends on the facility of your
su(1) command. This should work on most operating systems:
su minivend <<EOF
/your/minivend/dir/bin/start
EOF
The EOF must be the only thing on the line (no leading or trailing whitespace).
If your su(1) command has a -c option (as most System 5 UNIXes
do) then you can just do:
su -c /your/minivend/dir/bin/start minivend
MiniVend can share product databases, session files, and any other databases.
To make a mall, where all merchants submit orders through one clearing house, simply share the session file among all of the merchants. Any ordered items from any of the catalogs will show up in the same shopping basket.
There are some caveats. It will be a good idea to add a product attribute that holds the merchant number, to distinguish between possibly identical part numbers. This would also mean using the SeparateItems directive to place all orders on a separate line. MiniVend 3.x does this automatically, provided the databases are set up as separate files using the ProductFiles directive.
Pricing information will only come through if the merchants all share a product database, or at least share a pricing database. If the second is desired, you must build a pricing database that holds all merchant part numbers, ensuring no two are the same, and configure the PriceBreaks directive to start at quantity 1.
You can easily have some merchants who share a database and order point, while others operate completely independent catalogs -- all running from the same MiniVend server.
MiniVend has product modifiers, or attributes, which can be carried around with the product.
You can use the SeparateItems directive or set the mv_separate_items variable on the order form to cause ordered items to be put on separate lines in the shopping basket. This makes size/color handling much easier for multiple items. They can be stacked, which means that you can add multiple instances of a size or color to an individual product within a shopping cart entry line, but this is too much trouble.
It is useful to maintain a separate database in the accessories file to build select and other menus for size selection. The results can key into an arbitrary database, allowing even more control.
The attribute information is placed on the form with form fields, like:
<INPUT TYPE=XXXXX NAME="[modifier-name size]" VALUE="[item-modifier size]">
The embedded Perl capability of MiniVend means that you can discover the number of items on order of each type, and build quite detailed input forms.
The MiniVend documentation has some examples which should help you.
As of MiniVend 3.0, the [item-accessories attribute] tag will automatically place a suitable select widget on an HTML form, and ``remember'' what should be selected. See the MiniVend documentation for Item Attributes.
As always, check the error log. The most common problem is something like:
minivend.com 3Ex5lvta:minivend.com - [01/Sep/1997:09:08:43] simple /cgi-bin/simple
> Encryption error:
>
If the key you are sending to has not been signed by another (trusted) user, then you will get error returns from some flavors of PGP, which causes the problem. The fix is to route the error output to /dev/null (at least on UNIX) by changing the EncryptProgram directive in catalog.cfg:
EncryptProgram /usr/local/bin/pgp -feat sales@your.com 2>/dev/null
On Windows or other operating systems, the only fix is to sign the key or otherwise prevent the error from occurring.
This depends on what you do with orders once you receive them by email.
Some
PC mail agents (notably Eudora) will decrypt the
PGP message embedded within the message text. In that case, you can simply embed the
[value mv_credit_card_info] call right in the message and be done with it.
If your mailer will not decrypt on the fly, the best way to read the credit card number is to set up
MIME encoding of the order email. To do this, find the order report you are using. In the standard demos it is
pages/ord/report.html or etc/report.
Set up two MIME regions in that file. First, at the top of the file:
[tag mime type TEXT/PLAIN; CHARSET=US-ASCII][/tag]
[tag mime Order Text]
ORDER DATE: [calc]localtime[/calc]
ORDER NUMBER: [value mv_order_number]
Name: [value name]
Company: [value company]
(Rest of order text, including item list)
[/tag]
Then, at the bottom of the report.html file, put the credit card info:
[if value mv_credit_card_info]
[tag mime type application/pgp-encrypted][/tag]
[tag mime Credit Card Information]
[value mv_credit_card_info]
[/tag]
[/if]
Once this is done, you can then read mail, using your PGP client as a helper application to decode the MIME attachment. This does not require a fancy setup -- you can use the standard MIT PGP 2.6.2 if desired. If you are using UNIX, set up as the helper for the MIME type application/pgp-encrypted:
xterm -e pgp -m %s
On windows, it might be:
c:\mycommands\pgp -m %s
More automated or user-friendly setups are left as an exercise for the user.
If it is simply the total number, extended according to quantity, then you can use the [nitems] tag.
If you need this number for use in an embedded Perl script, you will need
to set interpolate=1 (or user [[nitems]] in the old parser).
If it is the number of line items you need, then you can use a Perl script:
[perl carts]
$#{$Safe{'carts'}->{'main'}} + 1;
[/perl]
(The 'main' refers to the main shopping cart.)
If you have SeparateItems in effect, and need the number of unique items, you could use:
[perl]
$items = q{[item-list][item-code]|[/item-list]};
@items = split /\|/, $items;
$count = 0;
for (@items) {
$count++ unless $seen{$_}++;
}
$count;
[/perl]
That is because it is a demo. It is not intended to be a finished catalog, just a starting point.
Though the author likes to get reports of malfunctions in the demo, he feels absolutely no urgency about fixing or responding to such reports.
Though MiniVend has ODBC capability, the Microsoft Access ODBC driver is not a network driver. You cannot access it on a PC from your ISP or UNIX system.
However, you can turn it around. Once you have created a MySQL or other SQL database on the UNIX machine, you may then obtain the Windows ODBC driver for the database (mySQL has a package called myODBC) and use the UNIX database as a data source for your PC-based database program.
Here is a quick procedure that might get you started:
http://www.mysql.com
Install it on your UNIX box. On Linux it is as easy as getting the RPM distribution:
http://www.mysql.com/rpm/
You install it by typing, as root, rpm -i mysql-3.XX.XX.rpm. If you are not root, you will have to build the source distribution.
mysqladmin shutdown
safe_mysqld --skip-grant-tables &
Obviously, you will want to study mySQL permissions and set up some security pretty quickly. It has excellent capability in that area, and the FAQ will help you get over the hurdles.
mysqladmin create test_odbc
mysql test_odbc
Make an SQL query to set up a table, for example:
mysql> create table test_me ( code char(20), testdata char(20) );
Query OK, 0 rows affected (0.29 sec)
mysql> insert into test_me VALUES ('key1', 'data1');
Query OK, 1 rows affected (0.00 sec)
mysql> insert into test_me VALUES ('key2', 'data2');
Query OK, 1 rows affected (0.00 sec)
mysql>
http://www.mysql.com
You install this package on your Windows 95 or
NT box. It is a simple setup.exe process which leads you to the control panel for setting up an
ODBC data source. Set up a data source named
test_odbc that points to the database test_odbc on the
UNIX box. You will need to know the host name and the
port (usually 3306).
There are many possible causes for this error. Using MiniVend 3.08 and above, the main 3 are:
One possible cause is that you must define METHOD=POST in all of your forms, not METHOD=post. The lower case form is not recognized in the HTTP spec.
MiniVend 3.05 and later has a new TolerateGet directive which allows you to have forms with METHOD=GET. To use, set the session ID in your form
<INPUT TYPE=hidden NAME=mv_session_id VALUE="[data session id]">
then set TolerateGet Yes in minivend.cfg (the main configuration file) and use
METHOD=GET on forms that have problems.
This may prevent errors due to one of the causes above.
MiniVend has a facility that adds a parameter called source to the session database for that user.
You should give your partners a source code, which must contain at least one letter character (A-Za-z only). It is placed in the sourcing URL after two semicolons as a query string of:
;;Source1
If this is appended to the
URL with which the user calls MiniVend
it will then be placed in the session identifier source.
This URL:
C<<>A HREF="http://yourcatalog.com/cgi-bin/yourcat/sp_offer?;;Source1">
Special offer!</A>
Will yield Source1 from the MiniVend tag [data session source].
There are several ways, but this is a more complex question than it may seem like it is.
You will have to deal with bad email addresses, deciding which information to send, showing delivery times, etc. You also have to be very careful with credit card information -- if you have not taken the proper security measures (by enabling PGP credit card encryption or using CyberCash) you might just mail them their own unencrypted credit card number!
If you still decide to do this, then I will show what I consider to be the best method -- and Caveat Emptor.
Use a GlobalSub
This is the best way, as it is fairly secure. (In case you are one of those people who go light on the documentation 8-(, you will need to read it in this case.)
GlobalSub <<EOF
sub form_mail {
my($to, $subject, $reply, $body) = @_;
my($ok);
return '' unless $to;
$subject = 'Copy of your order' unless $subject;
$reply = '' unless defined $reply;
$reply = "Reply-to: $reply\n" if $reply;
$ok = 0;
SEND: {
open(Vend::FORMMAIL,"|$Vend::Cfg->{SendMailProgram} -t") or last SEND;
print Vend::FORMMAIL "To: $to\n", $reply, "Subject: $subject\n\n", $body
or last SEND;
close Vend::FORMMAIL or last SEND;
$ok = ($? == 0);
}
if (!$ok) {
logError("Unable to send mail using $Vend::Cfg->{SendMailProgram}\n" .
"To '$to'\n" .
"With subject '$subject'\n" .
"With reply-to '$reply'\n" .
"And body:\n$body");
}
return $ok ? 'Copy mailed to user.' : 'EMAIL COPY FAILED.';
}
EOF
The above routine can be called on the report.html page with:
[perl arg=sub interpolate=1] form_mail (
q{[value email]},
'Your order from mycompany.com',
'sales@mycompany.com',
<<'EndOfOrder' )
NAME: [value name]
ADDRESS: [value address]
[value city] [value state] [value zip] [value country]
[item-list]
[item-quantity] [item-code] [item-description] [item-price]
[/item-list]
SUBTOTAL: [subtotal]
SALESTAX: [salestax]
SHIPPING: [shipping]
TOTAL: [total-cost]
EndOfOrder
[/perl]
(With the old parser, you use [perl sub] ... [/perl] with double brackets around some of the inside MiniVend tags.)
Of course you can place any valid tags in the body -- which is that area before the EndOfOrder ``here document'' marker. The usual here document caveats apply -- must be by itself at the beginning of a line, with no trailing whitespace, and watch those carriage returns if you use a Wintel machine.
This is a warning from Perl indicating that an empty value was found where one is expected. The warning is left in so that you know that something is missing.
Whatever it is, it can be found at the specified ``chunk'', or line, of catalog.cfg -- if you use the #include capability, it would have to be factored in as well.
The usual reason is that a file is specified in one of the directives (usually one of Help SearchProfile OrderProfile Buttonbars UpsZoneFile) and does not exist. See the documentation for the directive on how the file name should be specified.
<H3> Mini-FAQ: Why isn't the error more enlightening?</H3>
Because Perl won't tell us what exactly went wrong -- see it's FAQ for why.
This is a fault in the order profile, and can be due to any of:
On earlier versions of MiniVend, the demo order profile was placed in an outboard file. On newer versions, it is embedded right in the checkout page. Try replacing [set checkout_profile] with:
[set checkout_profile]
&final=yes
&set=mv_Junk 1
[/set]
If the order completes, then you have a problem in your profile. Also,
check the RequiredFields directive in catalog.cfg, as that is set to name in the demo. If the name variable is blank, then you will find that the order doesn't complete.
The order profile must not have non-blank lines that don't contain valid check procedures (excluding comments). If you are using a Perl routine in the profile, as above, you must take care that the routine returns a valid check routine.
This is a bug in all versions of MiniVend prior to 3.12. Update to solve the problem.
Set mv_substring_match to yes (su=yes in one-clicks).
This most commonly happens when searching for non-ISO-8859 (Cyrillic, or characters like umlaut and eacute) characters in word-match mode. The problem is, that unless your locale is set up properly that Perl doesn't think a non-ISO-8859 and a space character is a boundary.
Also, if you are searching for non-alpha characters then they will also not be interpreted as word characters and the boundary problems will still exist.
(Thanks to Thomas ``Balu'' Walter for this answer.)
You can use MiniVend's II8N facilty via the Locale directive:
In catalog.cfg:
# to define the euro-Settings (PriceDivide is for converting from DM) Locale eur_EUR PriceDivide 1.95583 Locale eur_EUR p_cs_precedes 0 # this is great - you can even use HTML-Tags to display an euro-image Locale eur_EUR currency_symbol "<IMG src="/path/to/image/euro.gif">" Locale eur_EUR p_sep_by_space 2 Locale eur_EUR mon_decimal_point ,
# and the DM Locale de_DE Locale de_DE p_cs_precedes 0 Locale de_DE p_sep_by_space 2
On your pages (this is from a search results page, the [item-.... ...] notation may be different depending on your context):
[item-price]<br><!-- german is default --> [setlocale eur_EUR] [currency convert=1][item-field price][/currency]<br><!-- the euro --> [setlocale]
Any questions? Read the docs about ``Internationalization''.
MiniVend is not a lightweight program.
If you are running it on a low-end ISP whose major selling point is low cost, you will frequently find that MiniVend performance is very poor. This is due to either:
If your ISP uses IDE hard disks you can expect REALLY bad performance. IDE disks are very slow for multi-user machines, which should have SCSI if ANY swapping is to be done.
fork()
call to spawn multi-tasked servers, and without multi-tasked servers there
is a strong possibility of a memory leak -- especially if you use embedded
Perl or conditional tags.
That is because it is only useful for small product lines. It pulls out all keys from the entire database and iterates over them, which is not reasonable for more then 50 products or so (depending on your server speed).
A better approach is to use a search and browse by category, an example of which is given in the demo.
You could also try something like:
[perl arg=scratch]
$start = tag_data('session', 'arg') || 1;
$chunk = 1;
if($start =~ /(\d+):(\d*)/) {
$start = $1;
$chunk = $2 || 1;
}
$prev = $start - $chunk;
if($prev < 1) {
$prev = 0;
}
$Safe{'scratch'}{'start'} = $start;
$Safe{'scratch'}{'chunk'} = $chunk;
$Safe{'scratch'}{'next'} = $start + $chunk;
$Safe{'scratch'}{'prev'} = $prev;
$Safe{'scratch'}{'not_shown'} = 1; return '';
[/perl]
[search-region arg="
ra=yes
fm=[scratch first]
ml=[scratch chunk]
sp=browse
tf=category
to=f "]
[search-list]
[on-change 1]
[condition][item-field category][/condition]
<TABLE WIDTH="80%"><TR BGCOLOR="#cccccc" TEXT="WHITE"><TD ALIGN=CENTER>
<BR><H1>[item-field category]</H1>
</TD></TR></TABLE>
[/on-change 1]
<P>
[if-field image]
<IMG SRC="[item-field image]">
<P>
[/if-field]
<H2>[item-description]</H2>
<P>
[L]Catalog[/L] [L]Number[/L]: [item-code]
<P>
[L]Price[/L]: [item-price]
<P>
[page [item-code]]<IMG BORDER=0
SRC="details.gif" ALT="[L]More Info[/L]">[/page]
[order [item-code]]<IMG BORDER=0
SRC="ordernow.gif" ALT="[L]ORDER NOW[/L]">[/order]
[/search-list]
[/search-region]
[if scratch prev]
[page href=browse1 arg="[scratch prev]:[scratch chunk]"]
<B>[L]Previous[/L]</B>
</A>
[/if]
[if type=explicit compare="[calc]
[value mv_search_match_count] > [scratch next]
[/calc]"]
[page href=browse1 arg="[scratch next]:[scratch chunk]"]<B>[L]Next[/L]</B></A>
[/if]
First of all, did you index your 'code' field? The reason MiniVend doesn't do it for you is that every SQL database seems to do that a bit differently. Even then, you can do some stuff with MiniVend's COLUMN_DEF parameter:
Database products COLUMN_DEF code=char(16) PRIMARY KEY
That will index at least the code field for MySQL. Other databases differ.
MiniVend can return VERY fast SQL search results. But you need to at least give it something to work with. The proper method for fast selection is:
[sql type=list
query="select code,category,title,price from products" ]
Category: [sql-param category]<BR> Title: <A HREF="[area [sql-code]]"> [sql-param title] </A><BR> Price: <A HREF="[area order [sql-param 0]]"> [sql-param price] </A><BR>
[/sql]
IMPORTANT
NOTE: The sql-param tag did not accept named fields before MiniVend 3.12beta4. Access with
[sql-param n], where n is a modulus-zero positional field set from your query. In the example
above, code=0, category=1, title=2, price=3.
This is especially powerful when you consider a joined query like
SELECT code, price, title, extended.desc
FROM products, extended
WHERE products.category = 'Renaissance'
That will index at least the code field for MySQL. Other databases differ.
Don't forget that you must index your fields if you want fast searching with them as a criteria.
Here is a nice synonym for [sql type=list ...]:
[new]
[search-region arg="
st=sql
ml=1000
sq=select code,title,artist,price from products where code < '5'
"]
<PRE>
[search-list][item-code]: [item-param title] [item-param artist] [item-param price]
[/search-list] </PRE>
[/search-region]
To set up the simple demo catalog statically, all that is required is to put in catalog.cfg:
StaticDir /ext/htdocs/simple/static
StaticPath /simple/static
StaticAll Yes
StaticFly Yes
NoCache ord special
The root WWW directory (DocumentRoot) on my system is /ext/htdocs -- you would change your StaticDir accordingly. Make sure the directory is empty -- MiniVend will overwrite files there!
Then edit a couple of the pages -- catalog.html and results.html. They have ``dynamic'' elements, ones that prevent the static build for those two pages (and any searches calling them for a template) from succeeding. Insert anywhere in the page:
[tag flag build][/tag]
This tells the builder to go ahead and build the static page anyway, despite the dynamic elements. (The elements in this case are the Perl code telling the user their name in catalog.html, the dynamic ``Check Basket'' icon on the results page, and some sorting parameters that are not used in the one-click search.)
At that point, if you are in control of the MiniVend software directory and changed directory to it, you should be able to run:
bin/minivend -build simple
(Users who are provided a catalog without control of the server will not be able to do this. The administrator would need to get involved.)
You will see some output from the build command, giving you the status of the build for individual pages. (HINT: send the standard output to a file to get a full report.) It will show information like:
Checking page catalog ......................................done.
Checking page browse .......................................done.
Checking page canceled ...............skipping, dynamic elements.
...
Checking part number 00-0011................................done.
...
Checking part number 00-342.................................done.
Building page browse........................................done.
...
Building page catalog ......................................
>> found search mp=0/se=Renaissance.........................save.
>> found search mp=0/se=Impressionists......................save.
>> found search mp=0/se=Surrealists.........................save.
>> found search mp=0/se=Americana...........................save.
>> found search mp=0/se=Contemporary........................save.
done.
Building part number 00-0011................................done.
...
Building part number 00-342.................................done.
Re-checking /simple/static/scan5.html.......................none.
...
Re-checking /simple/static/scan3.html.......................none.
done.
Restart the server and re-enter the catalog. Now all accesses should be fast whenever possible. One-click searches and flypages are in static HTML space, and only orders and checkout ops should be parsed by MiniVend.
This should get you started -- see the documentation for more information, particularly the section on what are ``dynamic'' tags and how to flag databases as dynamic with the DynamicData directive.