webERP Manual
 ☜ Table of Contents
⬇Go to Bottom

Developing New Scripts

Directory Structure

The scripts that make up the system are seperated into several directories. However, the main bulk of the webERP scripts are in the top level directory.

Construction of new scripts should make use of the following building blocks that are used throughout the system.

⬆ Top

This page must be included and has the following functons:

⬆ Top

This file should be included after the variable $Title has been set to the name of the page. This file relies on config.php being already loaded, so (which in turn includes config.php) must be included before The code in this script has the following functions:

⬆ Top

This file contains the small logo, company name and copyright notice with the closing "" tags.

⬆ Top


The variables in config.php are available to all of tcripts that have included There are not many now most of the configuration is stored in the database using the config table. However, the variables that give the software the information to connect to the database such as datbase user, password and host, together with the database type - dbtype - in fact only mysql is supported but there are two libraries that can be used the mysqli and the old mysql functions. There are a couple of other variables including the timezone, $RootPath which is the directory where the web server holds the system files. Also the php error_reporting code.

Having started the page with and - and then finishing with much of the work to ensure a consistent look and feel is already done.

An Example webERP Script Template

Following from the discussion of the key component scripts of webERP, the general form of a webERP script would look like the following:


/* is the script that brings in session
 * management, database management, and performs
 * any other housekeeping tasks related to the running
 * of webERP. and so should be included right at the
 * top of every script.

/* A title for the script must be assigned prior to
 * including the script
$Title = _('Simple webERP Script');

/* The $ViewTopic variable should be set to the name
 * of the manual page for this functionality and the
 * $BookMark variable is the place in that manual page
 * specifically for this functionality
$ViewTopic = 'SimpleScript';
$BookMark = 'GeneralTopics';

/* The file sends all the http headers needed,
 * links in the style sheets and downloads any javascript
 * files that are needed. It also draws the header on the
 * screen. Muse be included before any output is sent to
 * the browser.

if (!isset($_POST['Submit'])) {
/* In this section should go the code to validate the data
 * submitted in the form, and if all is well it should
 * post that data to the database. If there is more than
 * one table to be updated that transactions should be used
 * in order to maintain the database integrity.
 * If the form does not validate then it processing can just
 * fall through to the next section, but show any required
 * messages.

/* This section is where any of the display code goes.
 * Typically this will contain a table of the existing data,
 * and a form for entry of new details.

/* Finally we must include to draw the footer on
 * the screen, display any error messages, and close off the
 * html tags in the page.
⬆ Top


The only time when it is not appropriate to include or is when a pdf script is to be created. Here the file PDFStarter.php contains the initiation of the session and the check for proper user authentication and authorisation for the specific page using the $PageSecurity variable which must be defined before PDFStarter.php is included. Normally, config.php and are included seperately (and before in PDF scripts. PDF report scripts all make use of the FPDF class by Olivier Plathey but previously a differnt class was used so there is an extension to this which translates the calls to the old pdf class to the FPDF class. Probably better to write new scripts using the FPDF syntax.

⬆ Top

Database Abstraction -

Whilst the system has been developed using MySql it has always been envisaged that users should not be forced to use Mysql - in keeping with open source principles. For this reason all requests of the database are made via abstraction functions in This policy has been rigorously maintained and developing extensions to the system which do not conform to this scheme would destroy the portability currently available between databases. Instead of using the PHP database specific functions then the functions defined in should be used

The full list of functions should be reviewed from the file includes/ - which contains the mysql specific abstraction functions. Only these functions should be used in other scripts. Care has been taken to ensure that standards compliant SQL is used throughout, to ensure any database conversion issues are minimal. SQL specific to any RDBMS even mysql should be avoided in favour of generic standards compliant SQL. There are instances where mysql specific SQL has been used such as INTERVAL and SHOW TABLES - these are historical.

⬆ Top

This script holds a number of functions for manipulating dates used throughout the system - these functions all depend upon the system configuration for SESSION['DefaultDateFormat']. Amongst the most useful:

⬆ Top

This script has some common functions used throughout the system - in particular:

⬆ Top


This script holds miscellaneous functions:

locale_number_format($Number, $DecimalPlaces=0)
Displays numbers in locale of the user. See Indian Numbering System in Manual, Multilanguage, Technical Overview.
 ⬆ Go to Top