Last release: 9.3 Monterosso (released May 29th, 2019). This documentation is about the 9.3 Monterosso release, if you need the documentation for a previous release please read the documentation file included in each downloaded package; the features described in this file refers to DaDaBIK Enterprise Version, some of these features might be not available for DaDaBIK Pro. Check the features comparison for further details.
What is DaDaBIK?
Upgrade from previous versions
Upgrade from BASIC to PRO/ENTERPRISE or from PRO to ENTERPRISE
DaDaBIK Wordpress Integration
Adding a new language translation and fix existing ones
Known bugs, limitations and unexpected behaviors
DaDaBIK is a no-code / low-code development platform and a Web application builder written in PHP. It allows you to easily create a highly customizable database front-end or a database-based Web application without coding. You can use it to create in a few minutes a very basic CRUD (Create, Read, Update, Delete) database front-end or to develop a more sophisticated database application. DaDaBIK was one of the very first RAD PHP tools focused on database applications (first version released in 2001) and it is still one of the most popular.
DaDaBIK uses the PDO extension in order to support as many DBMSs as possible, at the moment it officially supports MySQL, PostgreSQL, SQLite and Microsoft SQL Server.
- Forms generation/customization
- Datagrid generation/customization
- Datagrid HTML template customization
- Reports generation:
- simple reports, generated in a few click (choose chart type, how to aggregate data, what data to display )
- advanced reports, using custom SQL code
- 15 field types, including lookup fields
- Calculated fields
- Responsive front-end
- File uploading
- Master/detail views
- Duplication checking
- Granular permissions
- Integration with external user/group/password lists
- Record locking
- Record ownership authorizations
- CSV export
- Email alerts
- SQL logging (DaDaBIK Enterprise/Platinum only)
- Pre-defined/custom formatting rules
- Pre-defined/custom validation rules
- Custom pages in PHP or simple HTML
- Three graphic themes, two page layouts (left menu, top menu)
- Graphic layout customizable through a documented CSS file
- Front-end in 20 languages (English, Italian, Catalan, Croatian, Czech, Danish, Dutch, Estonian, Finnish, French, German, Hungarian, Polish, Portuguese, Rumanian, Russian, Slovak, Spanish, Swedish, Telugu).
DaDaBIK differs from software like PHPMyAdmin: it has not been created to
offer the complete administration of a database, but rather to allow the
creation of a customizable and user friendly database application. The
target of a DaDaBIK application can be the final user instead of a DB
[back to top]
- Short answer:
- DaDaBIK is a Web application written in PHP so you need a Web server (for example Apache), you need PHP and you need a DBMS (MySQL, PostgreSQL , SQLite or Microsoft SQL Server are supported). Since some of the PHP files are encrypted with IonCube, you also need the Free IonCube loader (version 10.1.x or higher is required).
- If you are building your Web application on-line, your hosting
provider has probably everything you need already set up. Please
check, at least, the availability of the IonCube loaders: some hosting
providers already have it installed, some others allow you to install
it but some providers could prevent the installation of PHP
extensions. If you want to use DaDaBIK on your local computer
and you don't know what a Web server is or you don't know how to
install it you can download and install an application like MAMP,
which automatically installs on your computer Apache, PHP and MySQL.
The requirements, as you can see from the next section, are low; the vast majority of hosting services meet such requirements.
We suggest, among the others, A2HOSTING, which offers a good shared hosting service at about 4 euros / month, 100% compatible with DaDaBIK (we tested it), with IonCube already installed and four options for the location of the server: USA (Michigan), USA (Arizona), Europe (Amsterdam) or Asia (Singapore).
- Some more details:
- version >= 5.3.11 (PHP 7 and above is OK!). DaDaBIK can also work with
PHP 5.2 but contact us for details.
- with the mbstring extension enabled if you need to handle Multibyte character
- with LDAP support enabled if you need LDAP authentication
- The IonCube loader
- MySQL or PostgreSQL or SQLite or Microsoft SQL Server:
- MySQL version >= 5.0 (PDO_MYSQL PHP driver required)
- PostgreSQL version >= 7.4 (PDO_PGSQL PHP driver required)
- SQLite version >= 3
- MS SQL Server version >= 2012 (MS SQL Server on Azure is also OK) (PDO_SQLSRV PHP driver required; since this driver only supports PHP 7, with MS SQL Server you cannot use PHP 5)
- A pre-existent database (MySQL or PostgreSQL or SQLite or MS SQL Server) with AT
LEAST ONE table: with DaDaBIK you create database applications, not
the database itself. For MySQL, a great free tool to create databases
If you just want to use one of the prepackaged applications provided with DaDaBIK OR you want to build a DaDaBIK application starting from an Excel/CSV/ODS file, you don't need any pre-existent table.
For MySQL, all the database tables must be InnoDB if you want to correctly handle transactions; DaDaBIK can also work with MyISAM tables but it cannot guarantee that transactions are processed correctly.
To prevent SQL injection vulnerabilities you have to follow these rules:
- for PostgreSQL, standard_conforming_strings must be ON (if you have a recent PostgreSQL, it should be ON by default)
- for SQLite, the database must be in UTF8.
UTF8 is the character encoding strongly recommended also for MySQL, PostgreSQL and MS SQL Server.
In particular for MS SQL Server DaDaBIK expects Unicode content, this means the use of nchar, nvarchar, ntext, etc ... field types instead of char, varchar, text. DaDaBIK by default sends to MS SQL Server unicode strings. It has been tested with database having both ASCII and Unicode content.
- DaDABIK works with any modern browser; if you use Internet Explorer, cascade dropdown menu and custom required functions need at least Internet Explorer 8.
Not sure if your system matches the requirements? Most probably it does, but if you want to be sure contact us and we will check it for you.
DaDaBIK is not free software, it is released under the DaDaBIK license (see https://dadabik.com/index.php?function=show_license) and its use requires to purchase a regular license from the Website www.dadabik.com. For some of the files that compose the DaDaBIK package, you get the full source code and you can modify it.[back to top]
On our YouTube channel you can find a beginner video tutorial and some more advanced tutorials in the series "How to create a Web Application with DaDaBIK"
[back to top]
- READ the requirements
- Copy all the files contained in the program_files folder in a directory of your choice under your Web server, e.g. "my_dadabik_directory"
- Open the file /include/config.php with a plain text editor and edit it (specify at least the REQUIRED parameters)
- Run the file http://yoursite.com/my_dadabik_directory/install.php to install DaDaBIK
- Open the file http://yoursite.com/my_dadabik_directory/index.php in your browser to start using DaDaBIK.
- Have fun! :)
You can upgrade to the latest version without loosing your application's configuration if you are running at least version 5.0:
- Replace all the old files with the new ones but:
- keep your upload folder if you want to save the uploaded files, but BE SURE the folder is protected, see Security section
- custom_functions.php and custom_functions.js: if you have edited the files you can keep your version; however, since the default custom_functions.php and custom_functions.js files may change when a new version comes out (for example, more documentation in form of comments can be available, and this may affect your functions), you should, instead, read the new custom_functions.php and custom_functions.js files and then copy your custom functions in the new files. Normally, if there are changes in the files that you should be aware of, this is also mentioned in the changelog file.
- keep your custom language files if you have created any
- keep your config_custom.php file (if any, the file is available only starting from DaDaBIK 9.3)
- if you modified any of the other DaDaBIK files (including /templates/default_header_no_template.html and /templates/default_footer_no_template.html) you have to re-apply the modifications to the new files
- Upgrade the Wordpress plugin in the Wordpress installations where you have used it (if any)
- If you set your configuration parameters in config_custom.php and you kept config.php untouched (you can do that starting from DaDaBIK 9.3), skip to the next point; otherwise, if you edited config.php, update your new /include/config.php file using your old configuration settings; don't substitute the new file with the old one but MANUALLY edit the new file according to your old configuration.
- Run the file http://your_host/your_dir/upgrade.php and follow the instructions to upgrade DaDaBIK
- After having upgraded, it's a good security practice to change the parameter $dadabik_session_name in config.php or config_custom.php (and in the Wordpress DaDaBIK Wrapper if you use it) using a name you haven't used in the past; this allows to make invalid all the current sessions, that might have potentially dangerous content (think about a security fix) or content not compatible with the new version.
Please note that, due to SQLite limitations, the upgrade script is available just for MySQL and PostgreSQL.
You can upgrade from DaDaBIK PRO to ENTERPRISE or PLATINUM following the same instructions of the previous paragraph ("Upgrade from previous version"); this also apply if the version number is the same (e.g. you want to upgrade from DaDaBIK 8.3 Pro to DaDaBIK 8.3 ENTERPRISE). [back to top]
The configuration of DaDaBIK can be managed at two different levels.
Some very general configuration parameters can be directly set from the file /include/config.php, just by opening it with a plain text editor and editing it. The file is self-explanatory. At that level you can, for example, set the database you want to manage with DaDaBIK or configure some DaDaBIK features (e.g. authentication, upload, email notices, language,...).
For a more analytic tuning you are supposed to use the admin area http://your_host/your_dir/admin.php. At this level you can:
- Choose the pages that compose your applications; a page in DaDaBIK application can consist of:
- a set of search/insert/edit forms, results grid and reporting tools related to a database table or a database view; DaDaBIK automatically creates this set for each table/view you have in your database, trying to guess the correct settings according to your schema but you can customize it (see "Configure your datagrids" and "Configure your forms" later)
- a custom HTML page (you write your custom HTML code)
- a custom PHP page (you write your custom PHP code) (DaDaBIK Enterprise/Platinum only)
- a link to an internal or external URL
- Configure your data grids, choosing between a classic tabular data grid view (default) or a custom results page completely customizable using HTML templates.
- Configure your forms: this is the core of a DaDaBIK application
configuration; here, for each field, you can set
- if the field must be included or not in search/insert/update forms and data grids
- its label
- its content (e.g. numeric, alphabetic, e-mail, url...)
- the HTML input type (e.g. textbox, dropdown menu...)
- the possible values, also driven from another table ("foreign key" lookup support)
- how the fields are arranged in each form
- custom formatting and validation functions
- search operators
- and more...
- Set the permissions (see the Permissions sections for more details)
- Synchronize your applications if you change the database schema
The admin area is also self-explanatory, so you can read most of the instructions on how to configure DaDaBIK by clicking on the help tooltips available in the admin area itself. That's the reason why we kept this manual short, you will find everything you need about configuration in the admin section. Here we will only focus on documenting a few typical use cases:
- How to configure a drop-down lookup field
- How to hide a field from a form
- How to manage uploaded file (images and other files) fields
- How to configure a master/details view
- How to create a pre-filtered results grid
- How to create graphic reports
- How to create a completely custom page
- What is a hook and how to add some PHP custom codes to the DaDaBIK's workflow
- How to use calculated fields
- How to share the same database between two or more DaDaBIK applications
See the related following paragraphs for further details.
Some graphic customization can be done by changing the files /include/header.php and /include/footer.php and by editing the CSS file /css/styles_screen.css. In addition, the datagrid HTML templates feature allows you to deeply customize the appearance of your item results page.
If you want to customize the sentences used by DaDaBIK you can create your own custom language file, see Adding a new language translation and fix existing ones later
How to configure a drop-down lookup field
A lookup field is a field whose value is bound to another value in a source data table. For example let's say you have a table customers having, among the others, the fields address and city. Instead of setting the the field city as textbox, you want to provide the user a drop-down list which takes its values from a table cities having as fields ID and name. All you have to do is setting the following values (in the forms configurator), for the field city in the table customers:
- Field type: select_single
- Lookup table name: cities
- Lookup table primary key field: ID
- Lookup table linked fields: name
Configuring the field in this way, for the field customers.city you save in your database the ID of the city but you show to your users the name of the city. Also, you limit the options available to the cities you have in the table cities. The field customers.city needs to have the same database type the field cities.ID has, so if the ID is INTEGER, customers.city needs to be integer as well.
The select_single (drop-down list) is not the only DaDaBIK field compatible with the lookup approach: you can also use radio buttons, a list of checkboxes or a drop-down multiple select: all you have to do is selecting the right DaDaBIK field type: instead of select_single you need, respectively, select_single_radio, select_multiple_checkbox or select_multiple_menu.
It's worth mentioning that you are not limited to one linked field, you can add as many linked fields as you want. Let's say the table cities contains also the name of the region each city belongs to: cities (ID, name, region_name); you can add region_name as an additional linked field so that users will see in the drop-down menu not only the name of the city but also the name of the relative region.
For additional options related to lookup fields, including cascade fields, filtered lookup and the possibility to add a new item to a list on the fly, please refer to the in-line helps available for each parameter in forms configurator.
How to hide a field from a form
Hiding a field from a form or from the results grid is very simple: let's say you have a field salary in a table employees and you want to show the field only to some of your users, the users belonging to the group human resources. From the permissions menu of the admin section, choose employees as a table and, for each group, set the permissions: you probably want to set, for all groups except from admin and human resources, the permissions to NO for all the operations: RESULTS, EDIT, CREATE, DETAILS, QUICK SEARCH and SEARCH; the effect is that DaDaBIK will never show the field, the field will be excluded from the results grid, from the edit form, from the "create new" form, from the details page, from the quick search form (the boxes on the top of the results grid) and from the search form.
Please note that normally if you have a field which is auto-increment, you need to hide it form the CREATE form since the value needs to be assigned automatically from your DBMS (MySQL, PostrgreSQL, SQLite, MS SQL Server) and not entered by the user.
The permissions menu is used to set the presence of fields, as explained above, only if granular permissions are enabled (parameter $enable_granular_permissions in config.php), which is the default settings. If granular permissions are disabled, you can choose to hide a field directly from the forms configurator, in this case you set the presence of a field globally, for all the users.
How to manage uploaded file (images and other files) fields
DaDaBIK has two file field types, generic_file and image_file; both the field types generate in insert/edit forms an upload control that allows users to upload files. The difference between the generic_file and the image_file lies in how the file is displayed in the results grid and in the details page: for image_file fields, the actual image is displayed (using the img html tag), for generic_file fields, a link to the file is displayed.
To use the upload function you have to set the proper $upload_directory in config.php, the files uploaded, in fact, are not stored directly in the database but in the file system, the database stores just a reference to the file. From config.php you can also set the upload allowed file extensions and the size of the image thumbnails to show in results grid and details page. Please note that DaDaBIK automatically assignes a unique file name to the file the user uploads.
How to create a Master/Details view (subforms)
A Master/Details view (also called subform) is an edit form (or a details page) that shows not only the details of a records but also one or more result grids displaying related records from other tables.
A typical example is the representation of an invoice (or an order):
Invoice n. 1 date 08/04/2017
Customer Bob Smith
Product Quantity Price
iPhone 7 1 700
USB Key 2 20
You probably represent the information using two tables:
(you probably want to store information related to products in a third
table but let's keep the example simple)
The best way to represent this data in a DaDaBIK application is to create a master/details view with invoices and invoice_items: from the form configurator select id_invoice (the primary key of the invoices table) and add invoice_items as master/details, selecting id_invoice as foreign key:You can add as many details tables as you want to the same master.
How to create a pre-filtered results grid using VIEWS
Sometimes you want to show to your users a pre-filtered version of your data. Let's say for example you have a table products containing a field quantity_product, which stores, for each product, the quantity you have in your warehouse. If the table products is installed in DaDaBIK, it can be accessed from a menu item products and users can also execute search operations over it, for example, through the search form, they can ask to see only the products having a quantity value less than 10. If you realize that such query is quite common, you might want to offer to your users a direct access to the products having a quantity value less than 10, without forcing them to perform a search operation every time. You can do this using VIEWS.
A database view, informally, can be defined as a "virtual table" which is based on a real table; for example we can create a view products_low_stock based on the table products with this simple SQL statement:
The view products_low_stock can be installed in DaDaBIK as it was a normal table and therefore you can assign to it a menu item that allows users to directly access the products with low stock level in one click, without performing a search operation. Every time you access the view products_low_stock, your DBMS implicitly execute the query "SELECT * FROM products where quantity_product < 10" and provides you with the up-to-date results.
You can create a database view directly in DaDaBIK, admin section, pages menu:
For additional information about databaseviews, the Wikipedia entry is simple and quite informative: https://en.wikipedia.org/wiki/View_(SQL). A creative use of database views can help you in the process of creating very complex DaDaBIK applications.
How to create graphic reports
(DaDaBIK Enterprise/Platinum only)
Starting from the results grid of any page based on tables/views you can create a graphic report; several chart types are available, including bar charts, line charts, pie charts and doughnut charts.
DaDaBIK provides two types of reports: simple reports and advanced SQL reports. You can create a simple report in a couple of clicks by selecting the field you want to put on your X-axis and the field you want to put on your Y-axis. Normally you want to aggregate data according to a field, show each group of data on your X-axis and and show some information related to each group on your Y-axis.
For example you might want to see the age composition of your customers: in this case you would choose to aggregate data by age and to show, for each group, the number of customers having that age (selecting the count option).
A slightly more complicated example: you have a table sales containing, among the other information, the date of the order and the amount. You want to see your revenues, month by month. In this case you need to choose month month - date_order for the X-axis and sum - amount for the Y-axis.
If you need more freedom, you can use the advanced SQL reports: you can specify your own SQL query, include a where clause, joining several tables and so on. The only constraints you have is: the query must be a SELECT statement where the first element you select will be used for the X-axis of the graph, the second element for the Y-axis.
Here is an example: let's say we have the following tables:
sales (id_sale, date_sale, customer_sale) - each sale can have several sale items:
sale_items (id_sale_item, id_sale (FK), id_product FK), quantity_sale_item) - each sale item refers a sale and a product
products (id_product, desc_product, price_product)
we want to show, for each month, the total revenues; here is an example of custom SQL report for MySQL:
If you have created a report and you want to easy access it later from the menu in one click, you can simply copy the URL you see in your browser when the report is displayed and create a custom page (having type = link) that points to this URL. Please note that, if the report has been generated after a search, the search filter is not saved together with the link. If you need to store a report based on a stable search filter, the best way is to create a VIEW and generate the report starting from that view.
How to create PDF reports / documents
(DaDaBIK Enterprise/Platinum only)
Starting from the details page or from the results grid of any page based on tables/views you can create a a PDF report/document by clicking on the PDF button. If you are in a details page, DaDaBIK will create a PDF document containing the information related to the record you are viewing; if you are in the results grid, DaDaBIK will create a PDF document containing the information related to all the records included in the current results set.
Please note that, in order to use this feature, the parameter $export_to_pdf_feature needs to be set to 1 in config.php (by default, it is set to 1); furthermore, the parameter $pdf_max_number_records allows you to control the maximum number of records you want to export: since the PDF export is a resource-consuming activity, if you have a table with a huge number of records you might want to limit the export to a specific number of records: users could launch the export on the entire table (without filtering it) and cause a system freeze.
If you launch the PDF generation without selecting a template (or selecting "No PDF template") from the template dropdown menu, DaDaBIK will apply a standard template: for each record, a row containing the field label (in bold) and the field value will be displayed for each field you have in your details page or results grid.
Your custom PDF template
You can, however, create your own template, choosing the position of the fields, adding graphic elements, text or any other content you might want to add to your PDF.
In DaDaBIK, the generation of a PDF document is handled by the well known TCPDF library; in particular by using the writeHTML method (see the documentation of the TCPDF class for additional details on the method), that converts an HTML page to a PDF document trying to preserve the graphic layout.
If you want to create a custom template, you have to create a file having extension .html and save it in the /templates folder: the file is just a standard HTML page that reproduces, in HTML, the PDF document you would like to get. A DaDaBIK template has two peculiarities respect to a normal HTML page:
- it always starts with the line <!-- DaDaBIK Template -->
- for each of the field you want to include in the template, you can add
the value of the field by using a placeholder, it is something
dadabik_field field_name dadabik_field
For example, let's say we have an IT Help Requests application where users can add their help requests and we want to provide a printed version of each request, which includes our logo, some of the fields displayed in a tabular fashion and a signature request for the manager: here is a very simple template that could satisfy our needs:
A template can be much more sophisticated and it can include (internal) CSS as well. While the final result is not guaranteed (some HTML tags or CSS attributes might be not supported by TCPDF), the TCPDF library tries to preserve your HTML layout as much as possible and does a very good job.
Once you have created your template and saved in the /templates folder, the template name (the part of the filename before .html) will appear as an option to choose in the template dropdown menu.
Please note that, if you are producing a PDF document starting from a master / details view, only the master part of the view is converted in PDF.
"Mail Merge" feature
The export to PDF feature applied to a record results set, in combination with the use of custom templates, guarantees results similar to the ones you can get using a typical "Mail Merge" feature available in Word Processors. Let's say for example that you want to send a (paper) mail to all your customers who live in a particular city: you can do it by searching the customers by city and export as PDF the results set, using a template that contains the letter and a name placeholder that will be automatically filled with the name of each of the customer.
Advanced PDF customizationThere are still a couple of things you can do to customize your PDF reports / documents.
The first one is related to the default DaDaBIK template: as we mentioned earlier, if you don't choose a template from the dropdown menu, DaDaBIK will use a default standard template; you can change the default header and footer of that template by editing the files default_header_no_template.html and default_footer_no_template.html (/templates folder): this allows, for example, to modify the CSS used by the default template.
The second things is related to some additional customization you can do on your custom templates. As we mention earlier, for each custom template you have to create a TemplateName.hml file in the /templates folder. In addition, you can create an (optional) TemplateName.php file that might contain the following items:
- the set_standard_pdf_parameters_custom() function
- the pdf_custom_code_after_addpage() function
- the MYPDF class, that extends the TCPDF class
The set_standard_pdf_parameters_custom() function overrides the set_standard_pdf_parameters() function, that DaDaBIK calls after the creation of a TCPDF object; in such function, some general characteristics of the document are set, for example margins and font (see set_standard_pdf_parameters() in /include/pdf_functions.php for details).
The pdf_custom_code_after_addpage() function is an optional function executed by DaDaBIK after the execution of the AddPage() method of the TCPDF class. In the following example the function adds a custom logo in the top left corner (coordinates 10,10), after the execution of AddPage():
Finally, the MYPDF class allows to customize even more a template, overriding some of the methods of the TCPDF class, for example the Header() and Footer() methods. In the following example the class overrides the Footer method, displaying - for the footer of every PDF page produced - a custom text in a 40x10 cell:
PDF and UTF-8 characters
In case you experience problems with some UTF-8 characters which are not displayed correctly in PDF, you can fix the problems by using a font that is able to display all the UTF-8 characters (the core TCPDF font used by default is not), for example freesans. You can find some instructions here: https://dadabik.com/forum/read.php?1,19987
Additional information about PDF generation
For additional information about TCPDF, please refer to its documentation.
(DaDaBIK Enterprise/Platinum only)
Some use cases:
- you want to add a button in your form that copies the content of a series of fields (e.g., in a customer registration form, the contact address fields) to a series of other fields (e.g., in a customer registration form, the invoice address fields)
- you want to add an "Approve" button at the top of your edit form that changes the status of your order from "waiting for approval" to "approved"
- you want to add an "Approve" button a the top of your edit form that
changes the status of your order from "waiting for approval" to
In /include/custom_functions.php you have to write (we'll see the meaning of all the options later):
If your callback function is, instead, a PHP function, you can write it in in /include/custom_functions.php.
Please note that, to enable custom button, you have to set $enable_custom_button_functions = 1 in config.php.
Let's see all the options you have when you define a custom button.
type, the type of callback function triggered by the button; the available options are:
- php_standard (a PHP function, executed by loading a page in the browser)
- php_ajax (a PHP function, executed asynchronously via AJAX)
callback_function, the name of the callback function (must start with "dadabik_")
permissions_needed, the permission the user needs to see/use the button; the available options are:
- none (permissions are not checked, the button is always shown)
show_in, where to show the button; the available options are:
shows the button, for the products table, both in the insert and edit forms.
position_form, this parameter adds additional details about the position: if you selected show_in: results_grid, you can choose between:
- top (at the top of the results grid)
- row (at each row of the results grid)
label_type, the available options are:
- fixed (the label of the button is exactly what you set for the parameter "label")
- language_file (the label of the button depends on the language set, what you set for the parameter "label" is the key to look at in the corresponding custom language file)
label, the label of the button
style, CSS style (if any) to add to the button
Let's see an example of php_standard function: we want to implement in the results grid, for each record of the orders table, a button that changes the status of the order.
In /include/custom_functions.php you have to write:
Since we have set, as a callback function, a PHP function, we have to write such function in /include/custom_functions.php
Please note that PHP callback functions normally are not used to produce output; php_ajax functions, in particular, rise errors if you produce output (via echo statements or in any other way).
A DaDaBIK hook allows you to write some custom PHP code to be called under certain circumstances.
There are two types of hooks: operational hooks and layout hooks; the first ones are triggered before/after some data operations, the second ones before / after some elements of the layout.
(DaDaBIK Enterprise/Platinum only)
DaDaBIK currently supports before insert, after insert, before update, after update and after delete hooks for each table installed in a DaDaBIK application, which means that for each table you can enrich the DaDaBIK workflow with your own code functions, that can be executed:
- before an insert operation (before insert hook)
- after an insert operation (after insert hook)
- before an update operation (before update hook)
- after an update operation (after update hook)
- after a delete operation (after delete hook)
The after insert, update and delete hook functions receive as parameter the value of the primary key field of the record just inserted (if it is an autoincrement field), updated or deleted.
The before update hook function receives as input the value of the PK of the field in update and (second parameter of the function) an associative array containing all the values the user filled in the update form (where the array element's key is the name of the field).
The before insert hook function receives as input an associative array containing all the values the user filled in the update form (where the array element's key is the name of the field).
Please note that on PostgreSQL the after insert hook doesn't fully work (it doesn't receive the value of the primary key of the record just inserted).
Let's say for example that, when a new order is inserted into your orders management application, you want to automatically update your stock: you can do it by using a hook; in particular if you store your orders in the orders table and your products information and quantity available in the products table, you can add an after insert hook on the table orders and write the code needed to update the records of the table products.
All your hooks functions must be written in the /include/custom_functions.php file
Let's say we want to send an email to a specific address when a new account is inserted in our system: this is a built-in DaDaBIK feature (see parameter $enable_insert_notice_email_sending in config.php) but let's say we don't to use the built-in feature and we want to implement it using our custom code. We could, as in the following example, define an after insert hook on the table accounts, setting the function that has to be executed (dadabik_send_notice_after_accounts_insert) and after we can write the code of the function, that retrieves the name of the account just inserted and send it via email to a specific address.
Let's to another example with the before insert hook: an interesting use of the before insert hook is the modification of a value inserted by the user before the corresponding record is actually inserted, by overriding the content of the $_POST array. For example, let's say that, for the table customers, we want to capitalize the first name of the customer before insertion.
Please note that:
- you can use any name for hook functions, but the name MUST start with dadabik_
- if you need to execute operations on the database, you have to add the global $conn; code line (as in the above example)
- the delete hook doesn't work after a "delete all" operation.
- for operational hooks, you don't have to worry about transactions in your code: the after insert, update and delete hook functions are executed inside a transaction that starts before the insert, update and delete operations are executed and ends after the hook functions execution; the before update hook is also inside the same transaction which starts before its execution.
- for each hook, you can call just ONE function; you cannot, for example, link two different functions to hooks['accounts']['delete']['after']
DaDaBIK currently support:
- header hook ($hooks['custom_header_1'])
- footer 1 hook ($hooks['custom_footer_1'])
- footer 2 hook ($hooks['custom_footer_2'])
- And, for each table/view:
- before results grid header hook ($hooks[TABLENAME]['resultsgrid_header']['before'])
- after results grid header hook ($hooks[TABLENAME]['resultsgrid_header']['after'])
- before edit form header hook ($hooks[TABLENAME]['edit_form_header']['before'])
- after edit form header hook ($hooks[TABLENAME]['edit_form_header']['after'])
- before insert form header hook ($hooks[TABLENAME]['insert_form_header']['before'])
- after insert form header hook ($hooks[TABLENAME]['insert_form_header']['after'])
- before search form header hook ($hooks[TABLENAME]['search_form_header']['before'])
- after search form header hook ($hooks[TABLENAME]['search_form_header']['after'])
- before details page header hook ($hooks[TABLENAME]['details_form_header']['before'])
- after details page header hook ($hooks[TABLENAME]['details_form_header']['after'])
Let's say for example that you want to display some contacts information in the footer of your application: you can do that by defining a footer 2 hook, which is triggered just before the end of the page (before the "p owered by: DaDaBIK database front-end" statement); here is an example (all your hook functions must be written in the /include/custom_functions.php file)
Let's do another example: you want to give some instructions to your users when they fill the insert form of the product table; you can do that by defining a before insert form header hook on the table products:
Please note that:
- you can use any name for hook functions, but the name MUST start with dadabik_
- the functions triggered by layout hooks normally contain just echo statements, but they can also be more complex, there is no limit.
- for each hook, you can call just ONE function; you cannot, for example, link two different functions to hooks['custom_footer_2']
Row-level Custom Filters
(DaDaBIK Enterprise/Platinum only)
Sometimes you need to filter, according to some criteria, the records of a table/view that a user can see.
Take a helpdesk application, for example: let's say the help requests are inserted by some managers and each help request is then assigned by a manger to a member of the IT staff group; you might need to filter the requests so that each member of the IT staff can only see/modify/delete the requests assigned to them.
If your criteria is based on record ownership (who, user or group, inserted the record is the one who can see and/or modify and/or delete the record) you can use simply use the owner permissions (see later in this manual), in all the other cases, you can use row-level custom filters.
To define a row-level custom filter for a table/view, you must add a line like the following one in your custom_functions.php file:
With the above line we are saying that we define a custom filter for the table requests and that the filter is generated by the custom function dadabik_custom_filter_requests(). Then we need to write such function in custom_functions.php, for example:
In our example we want to add, if the current user is part of the IT staff group (let's assume that the IT staff user groups has ID 3), an ADDITIONAL where clause, showing only the requests assigned to him/her (being assigned_to_request the field set by the IT manager). All the other users (not belonging to the id_group 3), instead, will see all the records.
$current_user and $current_id_group are two global variables provided by DaDaBIK, they contain the username and the group ID of the user currently logged. In case authentication is disabled, the two variables will be set as "nobody".
The filter defined in the function is applied on the top of other filters applied by the user (for example by executing a search) or generated by the owner permissions (if set).
Here are a few more examples of use cases where you might find row-level filters useful:
- In a sales management application, agents can only see orders related to their area
- In a multi-schools application, each principal or manager can only view data for students belonging to their school
- In the application for a physiotherapy practice, each therapist can only view data records belonging to their patients
Since you can create your own additional filter, you have a lot of flexibility; you can create very simple filters such as :
to show, for everybody, only the invoices where the field paid_invoice is 0 (in this case, the filter is basically an alternative to a VIEW) or complex filters based on very complex criteria / parameters, not necessarily related to the characteristics of the user logged.
Please note that you can use any name for the custom filter functions but the name MUST start with dadabik_
How to use calculated fields
(DaDaBIK Enterprise/Platinum only)
A calculated field is a form field whose value is not directly entered by the user but is calculated according to a function.
For example you might have a table products containing the fields price, tax, total_price and you want the field total_price to be computed as price + tax. To get this results, you just need to fill - for the field total_price in forms configurator - the parameter "Calculated field function", setting the name of a custom function that will handle the calculation, for example dadabik_get_total_price. Then you need to write the function's code in /include/custom_functions.php. Here is an example of the simple dadabik_get_total_price:
The /include/custom_functions.php contains all the instructions to write these functions correctly.
How to share the same database between two or more DaDaBIK applications
Sometimes you want to build two (or more) different DaDaBIK applications which work on the same data (i.e. on the same database).
For example you want to build:
- A backend/data-entry application, from which you modify/enter data, accessible only to some people and
- A simpler, read-only, publicly available application that users can access without logging in.
You can do it very easily following these simple rules:
- the database name (parameter $db_name) must be the same in all the config.php files
- the $prefix_internal_table parameter needs to be different and UNIQUE for each application
- use the $prefixes_to_exclude parameter to state, for each application, the prefixes (see previous rule) you have used in the other applications sharing the same database.
For example, if we have two applications sharing the same database, here is an example of config.php files
config.php application A
$db_name = 'my_database';
$prefix_internal_table = 'dadabik_1_';
config.php application B
$db_name = 'my_database';
$prefix_internal_table = 'dadabik_2_';
If you just want to make part of your application public, you should use the parameter $username_public_user (see the Authentication chapter for further details).
Custom pages and dashboards
As explained in the chapter "How to configure and customize a DaDaBIK application", with DaDaBIK, from the pages section of the administration interface, you can create pages based on a database table/view or custom HTML and PHP pages. PHP pages are custom pages running your custom PHP code and to run them you have to enable the feature from config.php ($enable_custom_php_pages = 1).
Custom pages can be used to create dashboards. A dashboard is a collection of information that represent, synthetically, some key indicators of your data/application. For example a typical dashboard might contain some graphic reports that represent aggregated data and some tabular reports.
Building a dashboard in DaDaBIK is very easy: first you create a custom (PHP or HTML) page, then you embed all the reports (graphic or tabular) you want by:
- clicking on the "show embed code" button you can find at the bottom of
each report in your DaDaBIK application (you can see it only if you are
logged in as admin)
- paste the code (it's pure HTML) into the source code of the custom page you have created (your dashaboard)
DaDaBIK is released together with a Wordpress plug-in which allows to integrate a DaDaBIK application into a Wordpress site's page.
Furthermore, users authenticated through Wordpress can also be (optionally) automatically authenticated into DaDaBIK too, without logging-in again. The Wordpress authentication feature requires that the DaDABIK application is installed in a subdirectory of the Wordpress site and that the same users (same username) is available both in Wordpress and DaDaBIK.
Follow the instruction included in the wordpress_plugin folder to install and configure the plugin.[back to top]
Authentication is enabled by default, which means that, in order to use an application created with DaDaBIK, you have to login. You can disable authentication by setting $enable_authentication = 0 in /include/config.php; while this is not recommended, it can be useful if you want to use DaDaBIK to create a public Web site.
DaDaBIK is released with the following default users:
- username: root; password: letizia (this is a user belonging to the admin group)
- username: alfonso; password: letizia (this is a user belonging to the normal group)
Admin users can not only use a DaDaBIK application but also configure it through the admin area; furthermore, they can add new users/groups and edit/delete existing ones.
If you want make part of your DaDaBIK application public and part private, for example you want to allow unathenticated users to read a public dataset or you want to open to the public a registration form or a contact form, you can still set $enable_authentication = 1 and then define who is the "public" user in config.php (parameter $username_public_user): unathenticated users will be granted with the permissions you assign to the group the public user belongs to.[back to top]
(DaDaBIK Enterprise/Platinum only)
Optionally, you can authenticate your users against an LDAP server. DaDaBIK has been tested with both Open LDAP and Microsoft Active Directory.
From /include/config.php you have to enable $ldap_authentication and specify all the parameters required for the connection. Users who authenticate using LDAP are then copied into the DaDaBIK users table and get assigned to a default (configurable) group. The aim of the copy is to allow the permissions setting, LDAP users authentication is always performed through the LDAP server.
Mixed authentication (some users authenticate against DaDaBIK, others against an LDAP server) is also possible: during the log-in procedure, a user can check/uncheck the LDAP checkbox in order to specify if he is going to authenticate through LDAP or not.[back to top]
If DaDaBIK is integrated into a Wordpress site, users authenticated through Wordpress can also be (optionally) automatically authenticated into DaDaBIK too, without doing the log-in again. See DaDaBIK Wordpress Integration for further details.[back to top]
For each table (each form and field), through the permissions manager, you can set which operations (Read, Create, Edit, Delete and Details) are allowed.
If you disable the read permission for a table, the related item won't be displayed in the menu of the application. Remember, however, that users can still read its records if the table is used as source of a select_single/select_multiple field or as items table in a master/details view.
If $enable_granular_permissions is set to 1 (this is the default settings) in /include/config.php you can set, through the permissions manager, which operations (Read, Create, Edit, Delete and Details) are allowed for each users group on each form and field.
For example you can configure your application to allow the group "Managers" to read and modify all the forms while the group "Employees" to read all the forms and modify just some of them, or just some fields of them.
As we said for the basic permissions, if you disable the read permission for a table, the related item won't be displayed in the menu of the application. Remember, however, that users can still read its records if the table is used as source of a select_single/select_multiple field or as items table in a master/details view.
Integration with existing user and group lists
(DaDaBIK Enterprise/Platinum only)
DaDaBIK uses by default the table dadabik_users and dadabik_groups to store users information, but you can also use existing user and group tables. This help the integration of DaDaBIK with existing applications, for example with a CMS.
To set DaDaBIK to use your own users and groups table, you have to configure the parameters starting with $users_table_ and $groups_table_ in /include/config.php; the integration is also possible if your users table doesn't use the same password encryption which DaDaBIK uses, in this case you have to customize the hashing functions as explained in /include/config.php
(DaDaBIK Enterprise/Platinum only)
An owner permissions model is also available, it allows to set-up the application in a way such as users can:
- Delete only their own records
- Modify only their own records
- View only their own records
You can enable this feature from the permissions manager; to enable it, authentication must be enabled and each table you want to protect must have a field whose DaDaBIK field type is set to ID_user. When a field is set to ID_user, the username of the current user will be automatically inserted by DaDaBIK into this field when you insert a new record. If you want to base the ownership on the group instead of the user, change $use_id_group_for_ownership in /include/config.php
Please note that you can enable the owner permissions also for VIEWS, but also for VIEWS (as for TABLES) you need a working ID_user field, VIEWS don't automatically inherit form settings from the underlying tables. In some cases, however, you cannot directly insert records into a view (the DBMS won't allow you to do it, to read some more details related to MySQL see https://dev.mysql.com/doc/refman/5.7/en/view-updatability.html) so the correct ID_user value must come from the underlying tables.[back to top]
Some of the language translations are incomplete. If you open your language file (e.g. include/languages/spanish.php ) you can find the sentences not translated looking at the // to change comments at the end of each file row. You can complete the translation if you want. You are more than welcome to contribute to the localization sending back to info at dadabik dot org your improved translation.
A better way to modify a translation if you don't like the original one, however, is to use, instead of the original file (e.g. english.php) the corresponding custom file (english_custom.php); this is very useful to avoid loosing your custom translations during the upgrade of DaDaBIK. It is also possible to differentiate your custom translations according to the table the user is using. Open the file include/languages/english_custom.php to read the simple instructions you need to override an original translation.
Adding a new language translation is also pretty straightforward. For example, imagine you want to add Hindi: you just need to create a copy of the file /include/languages/english.php, rename it as hindi.php, and edit all the sentences of the file (for each row, the quoted part after the arrow). You can then add the language to the list of available choices adding 'hindi' to the parameter $languages_ar is /include/config.php.[back to top]
Here is some security-related information which you must know:
- If your DaDaBIK instance is public and you have disabled authentication (by default IS enabled), please consider disabling the export to CSV feature from /include/config.php because robots, accessing the CSV export link, could consume an inordinate amount of processor time.
- You should protect the upload directory from public access, otherwise anyone who knows the URL of a file you have uploaded via DaDaBIK can access the file itself, even without logging-in. By default, the /uploads folder contains an .htaccess file which should prevent public access on Apache, please test it because it might not work in your environment; if you change the default upload directory or use a different Web server than Apache you should provide the needed security by yourself.
- If you use SQLite, you should store your SQLite database file outside the Web root or protect it from public acces, otherwise anyone who knows the URL of the file can access it, even without logging-in.
- You should protect the templates directory from public access, otherwise anyone who knows the URL of a template file can access the file itself, even without logging-in. Normally template files don't contain private information but they could. By default, the /templates folder contains an .htaccess file which should prevent public access on Apache, please test it because it might not work in your environment; if you use a different Web server than Apache you should provide the needed security by yourself.
- After having installed and configured a DaDaBIK application, it's a good practice to remove the files install.php and upgrade.php, since they could be used by malicious users in order to change or even re-install your DaDaBIK installation.
- The files admin.php, datagrid_configurator.php, db_synchro.php, internal_table_manager.php, permissions_manager.php and tables_inclusion.php can also be used to modify your application. If authentication is enabled, the access to the files will be protected, otherwise you should remove those files. For additional security, you can however remove the files even if authentication is enabled.
Please read the FAQ document.[back to top]
- UTF-8 related:
- DaDaBIK supports UTF-8; however, malformed UTF-8 characters can lead to unexpected results such as content corruption. The use of the HTML content type or of the rich text editor, in combination with UTF-8 content, is another factor that could lead, theoretically, to unexpected results.
- Security/data-integrity related:
- Table and field names related:
- The use, in a DaDaBIK application, of tables and fields whose names contain quote characters (such as ' ` "), blank spaces, semicolumns, dots and characters which need to be escaped (such as \, NULL byte) can lead to problems and security issues. The same for field names containing the value set in config.php for the parameters $alias_prefix, $null_checkbox_prefix, $select_type_select_suffix. DaDaBIK, in case you are using table or field names containing such characters, displays a warning message; in some cases, the use of such characters can generate a query execution error.
- User interface related:
- Some language translations are not completed. If you open your language file (e.g. include/languages/spanish.php ) you can find the sentences not translated looking at the // to change comments at the end of each file row. You can complete the translation if you want.
- The rich editor interface (TinyMCE) is displayed in english only.
- PosgreSQL related:
- DaDaBIK needs table names in lower case to work on PostgreSQL.
- If you use cascade fields and the cascade parent field is a numeric field, you might get a "SQLSTATE[22P02]: Invalid text representation" error.
- You can't use, for a DaDaBIK application, tables/views coming from different schemas, they need to be in the same database/schema.
- The insert e-mail notice doesn't work on PostgreSQL.
- Insert/update don't work correctly on PostgreSQL if the user choose "Other...." from a select_single field menu and the field has some linked fields.
- The after-insert hook doesn't fully work (it doesn't receive the value of the primary key of the record just inserted).
- MySQL related:
- DaDaBIK doesn't support the BIT MySQL field type.
- MS SQL Server related:
- You cannot specify the schema to use inside your database. When you build a DaDaBIK application on MS SQL Server, you specify a database and DaDaBIK, by default, reads all the tables belonging to all the schemas (you can, however, exclude tables by using the $tables_to_exclude setting in config.php). This also means that you cannot have two tables having the same name in two different schemas of the same database.
- Admin section related:
- The field renaming feature of the administration page doesn't work as expected if the renamed field is used in one of the following properties: "Primary key field", "Linked fields", "Order by", "Where clause" in the forms configurator related to any of the tables. In particular, after the renaming, you will get " Error: during query execution" messages from the DaDaBIK front end; you should edit the above properties by hand, renaming the field in the forms configurator.
- The "refresh installation" admin operation doesn't work correctly and could lead to a forms configurator settings loss if the installation is the result of an upgrade from a DaDaBIK version < 4.1 rc2; the "refresh installation" bug is considered fixed only for tables installed (DaDaBIK installation from scratch or single table installation from the admin interface) using a DaDaBIK version >= 4.1 rc2.
- The "previous" and "next" buttons don't work correctly after this sequence of operations: - perform a search based on a field A - change the value the field A for a record of the resultset
- Database BIT and Boolean field types at the moment are not fully supported, use INT (1/0) or char(Y/N) instead.
- Primary keys composed by multiple columns are not handled.
- Nested Master/Details views (a master/details view on a table which is already in a master/details view as details table) don't work correctly.
- Upload and deletion of multiple files during the same insert/update/delete operation are not considered as a unique atomic operation: e.g. if you are uploading multiple files from the same form and one of the uploads fails, other files already uploaded will result available in the file system.
- The "check for duplicated" feature doesn't work with file field types: DaDaBIK doesn't warn about similarity when two files have a similar name; furthermore, the "check for duplicated" feature causes uploads to fail during insert, in particular the files are not uploaded if some possible duplicated records are found and the user decides to insert it anyway. The "check for duplicated" feature also doesn't work with date, date_time, insert_date and update_date field typed and with all fields which are hidden in the insert form.
- HTML content is not set correctly as "Default value" (form configurator).
- When a new option of a select_single field with linked fields is inserted through the "other..." option, the current user is not inserted in the ID_user field of the linked table. This means that the new record in the linked table won't get an owner and the owner permissions won't work as expected.
- If, while editing a record, you change the value of the primary key, DaDaBIK is not able to show you the updated record after saving.
- If an insert/edit form needs to be re-displayed because an error occurred (e.g. a missing required field), FILE fields (only file fields) don't preserve the values set by the user before submitting the form
- The "insert as new" feature doesn't work for generic_file / image_file fields and if the record is a master of a master/details view, the details records are not inserted.
- If an image_file or generic_file field is used as a linked field for a lookup field, the file is not showed if the user doesn't have read permissions on the corresponding linked table.
- Unexpected behaviors (not really DaDaBIK bugs but behaviors which the average user doesn't expect)
- DaDaBIK relies on the $timezone parameter for date functions (e.g. to produce the current date), which can be different from the client's (user) one.
- The value actually inserted in the database during an insert/update, if the value typed in the form is not part of the domain specified during table creation (e.g. integer, varchar,...), depends on the DBMS settings and on the domain itself. For example if an integer field is left blank during insert/update (not NULL, blank), MySQL could insert 0 as value, because an empty string is not part of the integer domain and very often the default value for integers is set to 0.
- Formatting tags automatically inserted in a field through the HTML editor are not filtered during search so if you search "hey good" and you have "<b>hey</b> good morning" in your field you won't find it.
- If you set a master/details view between table A (master) and table B (details) and you perform a search on B and then access (in edit or details mode) a record of the table A, you will then lose the search filter you had in B.
- The Wordpress and DaDaBIK session expirations are not synchronized: if your session expires in Wordpress it doesn't mean it automatically expires in DaDaBIK. Use the logout button in Wordpress to be sure to disconnect to both Wordpress and DaDaBIK
- If you have enabled the Wordpress authentication, you should login/logout through Wordpress without using DaDaBIK login/lougout; mixing Wordpress and DaDaBIK login/logout can lead to unexpected behaviours.
- If an error occurs during installation or upgrade, the installation of DaDaBIK can ends up in a inconsistent state due to implicit commit policies of the DBMS.
- Old versions of Microsoft Excel for Mac can't correctly represent UTF-8 characters for CSV files produced by DaDaBIK
The content of this manual is copyrighted by Eugenio Tacchini