• A working HTTP web server eg. Apache, IIS.
  • A working MySQL server - with innodb tables enabled (see notes below)
  • PHP installed on the web server with MySQL support.
  • Adobe Acrobat Reader - or another PDF reader for viewing the PDF reports before printing them out.
  • php.ini may need to be edited to enable openssl and Apache restarted - XAMPP v1.8.1 SSL DLLs Path Fix
  • Connection to internet is essential so that COAs and other goodies can be downloaded from the and other personal / custom repos.
  • XAMPP related Forum Post
  • On IIS, use PHP Manager for IIS. It is a tool for managing one or many PHP installations on IIS 7 and IIS 7.5 servers. Will need MSVC runtimes.
  • On Kubuntu 13.1 trying to Install/Update Languages will result in an error that is resolved by increasing the session.gc_maxlifetime variable in php.ini
  • On CentOS 6.5, PHP 5.5, MySQL 5.5, Apache 2.2 the following was tested and found that Varnish HTTP accelerator was running in front of Apache and the default.vcl was configured to strip cookies. FrontAccounting needs to create a session cookie to work and hence this should be remedied.
  • Sending Mail from XAMPP (or from any Windows install of FA) using fake sendmail.
  • If you cannot use gettext language translations on some versions of PHP (5.3.0 to 5.3.5 or thereon) on Windows (XAMPP/WAMP) the use php-gettext as shown here instead of the PHP module. It may not work for some languages and some others may need some tweaks (like LANGUAGE instead of LANG parameter). GNU gettext for Windows is also available - v0.14.4 and v0.19.8.1.
  • When using FA in PHP 7.1.x, the constructors and destructors for all classes used must be renamed to __construct and __destruct as the old way of naming it as the class name is not only deprecated, it has now been removed in it's entirety from this version of PHP onwards. Forum Post: Fixes to all such files are provided for FA v2.4.2 as a patch file and as a commit by Paul Shipley as of 2017-10-02. This is now in the official FA 2.4.3+ Git Master.
  • Forum Post: Fixes for locale and openssl along with IIS7 and PHP 7.1.14 on Windows 10.
  • If there are random timeouts when using FA, then check if the following php.ini setting is a minimum of session.gc_maxlifetime = 1440

Important Notes

  • One critical aspect of the PHP installation is the setting of session.auto_start in the php.ini file. Some rpm distributions of PHP have the default setting of session.auto_start = 1. This starts a new session at the beginning of each script. However, this makes it impossible to instantiate any class objects that the system relies on. Classes are used extensively by this system. When sessions are required they are started by the system and this setting should be set as session.auto_start = 0.
  • For security reasons both Register Globals and Magic Quotes php settings should be set to Off. When FrontAccounting is used with www server running php as Apache module, respective flags are set in .htaccess file. When your server uses CGI interface to PHP you should set magic_quotes_gpc = 0 and register_globals = 0 in php.ini file.
  • Innodb tables must be enabled in the MySQL server. These tables allow database transactions which are a critical component of the software. This is enabled by default in the newer versions of MySQL. If you need to enable it yourself, consult the MySQL manual.
  • FrontAccounting is implemented and tested with MySQL. Generally it should work with other databases, but this is not supported in any way at the moment.
  • In order for the install script to run properly, the web-server process must have full read/write/execute access to the installation directory tree. For example, on Ubuntu 14.04 LTS Trusty, the apache2 web-server is user www-data and belongs to the www-data group, and these must have the respective permissions rwx and r-x on at least the following directories:
    • webroot directory of FrontAccounting (e.g. on Ubuntu the server webroot directory might be /var/www/html/frontacc)
    • lang/ subdirectory
    • modules/ subdirectory
    • company/* subdirectories
    • themes/* subdirectories (only if and when installing new themes)
    • sql/* (only if and when installing a new Chart of Accounts -- also known as CoA).
If you are running FrontAccounting for yourself on localhost and security is not an issue, you can achieve the proper permissions on Ubuntu for the webroot and all subdirectories by executing:
$ sudo chown -R www-data:www-data /var/www/html/frontacc
$ sudo chmod -R 755 /var/www/html/frontacc
where the -R option applies the changes recursively from webroot.
  • New installations will not have file called config.php and config_db.php. They get created by the install script. In order for it to be written, the webroot directory of the installation must have read/write/execute access for the web-server process at least. Other files created during a new install will be 2 installed_extensions.php files (both in webroot folder and in the company/0/ folder - the files are slightly different) and lang/ besides any extensions downloaded during the install.

Copying all the project files to the correct directory

  • You must obviously have downloaded the project archive to be reading this file.
  • All the files inside this archive should be copied to a directory under the web server root directory.
  • For example, create a folder called /account, and extract the archive into this folder.
  • If you have a dedicated machine or VPS, then incorporate the contents of the .htaccess file into the apache conf file. In Debian, a sample apache conf file at /etc/apache2/sites-available/frontac would be like this.
  • Please note that FA has many file types like *.inc, *.sql, *.log, etc which may not have MIME association in Apache and will result in getting displayed as text in the browser if the .htaccess file or the apache conf file (as the case may be) is not properly done. No attempt to rename the *.inc files to *.inc.php is done as they would then be executable by the web server exposing them to RFI attacks needing ugly checks on every file like the one at the top of language.php file.

Installation Steps

  1. If you have the option to create multiple databases on your host, create one, for instance say frontacc (with collation type utf8_general_ci?), otherwise write down the database name for your account. At the same time look up the username and password for the database. You will need this information during the wizard install.
  2. Enter your_url/account (or whatever directory you entered). This will run the install wizard. If this is the first time you've run FrontAccounting, setup the training company (Training Co. by default) and, optionally, populate it with initial demo data by ticking (click) the check-box. It is a good idea to get familiar with the system before starting your own company. Later, you can create your own real company. You may also want to consider keeping the training company for training other/future employees.
  3. DB Clustering for Master to Master Replication: MariaDB (a drop in replacement for MySQL) as of v10.1 supports Galera Clustering and InnoDB whilst MyISAM is experimental. PDF Guide (Cache) with corrections included.
  4. Tax system configuration should be done when a company is setup.

Post Installation

  1. After FrontAccounting has been successfully installed, it is highly recommended to archive and remove or atleast cryptically rename, the install sub-directory for safety reasons. It is no longer needed.
  2. Make the tmp/ directory writable by the web-server process so that error.log files can be written.
  3. Change config_db.php and config.php to read-only.
  4. Import your Opening Balances if any.

Locked out on PHP / MySQL upgrade

Forum Post: Even though your username and password are correct, FA may deny access if there is no MySQL socket available as obtains when there has been a PHP / MySQL upgrade. Check tmp/error.log for any errors.

Making a training copy.

It is very often useful to have a complete copy of a FrontAccounting installation for training purposes. The following script will make a safety dump of a live site and load it as a copy of that site.

Please note - this does not use the same FA installation to run the training copy - but uses a whole FA installation. This is useful as it is then possible to have the sites running at different addresses - for example - and For this to work there should be a separate MySQL database set up and a separate vhost set up.

Please note as well - this is based on using Apache ITK which means that the Apache process runs as an assigned user and so all files can belong to the same server account. This cuts out the issue of files needing to be uploaded as one user then accessible/modifiable by the Apache user (on Debian this is www-data).


# copy_accounts_to_accounts2

# ----------------------------------------------------------------------------------
# This will take a copy of the live FrontAccounting site and copy it to a training copy.
# ----------------------------------------------------------------------------------

# -------------------------------------------------------------------------------------------------
# Logging setup
# -------------------------------------------------------------------------------------------------

# Here we can save the output from running this script to a log file.
# These lines have been copied from 
# and will send the script output to a log file.
# Uncomment them if you want to use them.
#mkdir -p ~/logs
#DATE_TIME=`date +%Y%m%d-%H%M%S`
#mkfifo ${logfile}.pipe
#tee < ${logfile}.pipe $logfile &
#exec &> ${logfile}.pipe
#rm ${logfile}.pipe

DATE_TIME=`date +%Y%m%d-%H%M%S`

# -------------------------------------------------------------------------------------------------
echo `date`
echo "Backup primary site..."
# -------------------------------------------------------------------------------------------------

# Here we will create backups which are datetime stamped to be able to go back to a previous 
# version if necessary.
mkdir -p /home/frontacc/backups
mysqldump frontacc > /home/frontacc/backups/${DATE_TIME}_frontacc.sql
tar --create --file=/home/frontacc/backups/${DATE_TIME}_frontacc.tar /home/frontacc/public_html

# Here we will make a backup to a standard location so that it is backed up by backup scripts.
# This will also be the backup we will load into the copy site.
mysqldump frontacc > /var/backups/frontacc.sql
tar --create --file=/var/backups/frontacc.tar /home/frontacc/public_html

# -------------------------------------------------------------------------------------------------
echo `date`
echo "Load the backup into the site..."
# -------------------------------------------------------------------------------------------------
mysqladmin --force drop frontacc2
mysqladmin create frontacc2

mysql frontacc2 < /var/backups/frontacc.sql

rm -r /home/frontacc2/public_html/*
tar -x --file=/var/backups/frontacc.tar --directory=/home/frontacc2/public_html --strip-components=3 

# We need to change ownership for the files just unzipped.
chown -R frontacc2:frontacc2 /home/frontacc2/public_html

# -------------------------------------------------------------------------------------------------
echo `date`
echo "Change the database settings - this could probably be done better..."
# -------------------------------------------------------------------------------------------------
sed -i 's/Company Name/Company Name2/g' /home/frontacc2/public_html/config_db.php
sed -i 's/frontacc/frontacc2/g' /home/frontacc2/public_html/config_db.php
sed -i 's/live_copy_mysql_password/training_copy_mysql_password/g' /home/frontacc2/public_html/config_db.php

# -------------------------------------------------------------------------------------------------
echo `date`
echo "Setting up the copy site with a different appearance from the live site..."
# -------------------------------------------------------------------------------------------------
# This is useful to make help the users to see which site they are working on.
# Again, there may be a more elegant solution for this.
sed -i 's/285b86/ff0000/g' /home/frontacc2/public_html/themes/default/default.css

# -------------------------------------------------------------------------------------------------
echo `date`
echo "A restart of Apache is needed for the site to work..."
# -------------------------------------------------------------------------------------------------
/usr/sbin/apache2ctl restart

# -------------------------------------------------------------------------------------------------
echo `date`
echo "Finished"
# -------------------------------------------------------------------------------------------------