The “Installation” window sets the store’s initial parameters on the server: database access, language and character sets, parser behaviour, access restrictions, and it also performs a full copy and restore of the store.
The settings are read from the server when the window opens and written back with the “Save” button; “Cancel” closes the window without changing anything.
The section is meant for the initial setup and for one-off jobs. A mistake in these parameters stops the whole store.
Database — Host, Database name, User, Password, Table prefix, Table charset, Table engine, and Temporary tables. The prefix makes it possible to keep several stores in one database. The “Additional commands for the DBMS” field is executed on every connection — that is where the settings a particular server requires are put.
The group’s buttons:
Warning! “Installation” destroys all the store’s data. The application asks for confirmation.
Store and application — Time zone, Primary language, Encoding, and Character set.
Parser — Caching (on or off as a whole), Primary template, Site path, Build, and Debugger password. These parameters are covered in more detail in the developer guide, “Configuration”.
The “Access from IP” field limits the circle of
those who may work with the store: individual addresses and masks of the
form 192.168.0-127.* are accepted. The administrators group
is always allowed in, so you cannot lock yourself out with this field.
The “Mine” button fills in the address you are working
from right now.
The “Blocking user access for backup” group — the start time and the end time of the daily window when the server does not let users into the store. It exists so that a backup taken by the hosting’s own means captures the data in a quiet state.
The “Keep a log of store users’ actions” checkbox turns on the recording of employees’ actions.
While the marker file admin.here lies in the store’s
root, the store runs in demonstration mode: no license is required, user
rights are not checked — whoever signs in counts as an administrator —
and no action log is kept. The marker is placed by the server
installation so that a new store can be entered before there is either a
license or a single employee.
In this mode a warning and a “Switch to working mode” button are visible at the top of the window. It deletes the marker, after which authentication, licensing, and the log come into force. Demonstration mode cannot be brought back from the application — the file is created only on the server.
The “Copying” tab collects the store into a single zip archive. The required kinds of data are ticked: the database, files (product and section images), PHP modules and HTML templates, local settings (table and column sizes, profiles); the “Select all” button ticks everything at once.
Copying a large store takes a long time. This function is intended for developers — to make a demo version, for example. For the store owner, a backup by the hosting’s own means will be faster and more reliable. Before starting, make sure nobody is working with the store.
The “Restoring” tab deploys a store from such an archive. The “Load store” button becomes available only after the confirmation checkbox, because the operation replaces the entire contents of the store.
The progress is visible step by step: unpacking the archive, loading modules and templates, loading the database, loading files. A step for which there is no data in the archive stays greyed out.
Warning! All the store’s current data will be lost.
The archive does not carry the database connection parameters: the configuration is the face of a particular installation, and the server keeps its own. So after restoring, check the “System” tab — the data is deployed into the database named there.
A restored store may turn out to be in demonstration mode — it can then be brought back to ordinary work with the “Switch to working mode” button.