Please note that in the "Fixed bugs" sections, the bugs are not just related to the previous version, most of the time they also affect other old releases. Please also note that some new features or changes can be related just to DaDaBIK PRO OR ENTERPRISE version.
Dec 22, 2014
Fixed bugs and changes
During an edit operation, if the edit form, after having pressed "save", needs to be re-displayed (e.g. because of a missing required field), a select_single field having an hard-coded list of options (non linked table) could loose the value set by the user and got the value stored in the database in that moment. This could lead to save wrong values if the user didn't re-check the whole form before saving. Fixed.
An update_date field didn't work correctly (date set to NULL after update) if $treat_blank_as_null was set to 1. Fixed.
Since DaDaBIK needed, to handle generic_file and image_file types, to upload the files into a folder which is public accessible, those files were accessible to anyone who knows their URL, even without logging in into the system. This could produce a false sense of security because users might think the files are, by default, password protected.
The file management has been completely rewritten and it is now possible to protect the upload folder in order to avoid public acces through the URLs. By default, the /uploads folder now 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 a field field1 has the edit permission set to "Yes, but disabled" an the edit form, after having clicked on "Save", needed to be showed again because of errors, the value of field1 is not correctly reported in the form. This bug has been fixed with version 6.2 but if the field was a select_single using a linked table, the fix didn't work. Fixed.
If the results template was enabled, DaDaBIK cut the last 6 characters of field values while displaying the data grid and didn't add a line break between values of a select_multiple_* field. Fixed.
Instructions about "Owner permissions" have been improved, in particular it has been highlighted how it works with VIEWS, which don't inherit form settings from the underlying tables.
It is now possible to set in the config file, for MySQL and PostgreSQL, a port different than the default one.
DaDaBIK produced some "undefined index" errors after a search if a date, date_time, insert_date or update_date field were included in the quick search bar; furthermore, the search value related to such a field is not correctly kept in the quick search bar. Fixed.
The queries executed during permission settings (admin) have been optimized in order to avoid (or make it very rare) a potential execution timeout due to the high number of fields and/or users.
DaDaBIK produced a "Notice: Uninitialized string offset" message in some situations. Fixed.
The bug about nested Master/Details views, highlighted in the "Known bugs" section of the on-line documentation, was not included in the documentation file released with DaDaBIK. Fixed.
DaDaBIK ENTERPRISE produced a " Error: during transaction start" error during insertion/update of a record if you chose "other" for a select_single field. Fixed.
The layout of the quick search bar now looks better when a field has just one search operator.
The documentation in config.php said the boolean search worked just for a “contains” search. It was not correct, it works also with other search operators. Fixed.
DaDaBIK didn't work correctly (although it didn't show any error) if a field name was longer than 50 characters. Fixed, now the length of table name plus field name can be up to 254 characters.
If you were working on a details table A (master/details view) and A doesn't have read permissions, clicking on the homepage link produced an error. Fixed.
If a required select_multiple field was not filled during EDIT, DaDaBIK produced a "undefined index" notice. Fixed.
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. This issue has been added to the known bugs.
DaDaBIK doesn't work correctly with VIEWS, if used in combination with SQLite (MySQL and Postgres work fine). We are working on a solution, the issue has been added to the known bugs.
In order to reduce risk of brute force attacks, a user account is blocked if the user types the wrong password for 10 times (you can change the value from config.php). If a user access a DaDaBIK application through a Wordpress authentication, this limit has no effect. This doesn't prevent bruce force attacks made by trying multiple usernames (not more than 10 times for each).
Permissions settings is now much faster: for each permission type (read, create, delete, ...) you can set "Yes" or "No" for all the fields of a table in one click.
It is now possible to fill ID_user fields with the group of the user instead of the username. The option must be enabled in config.php ($use_id_group_for_ownership). This also affects, for DaDaBIK ENTERPRISE, how the owner permissions work (id_group instead of username will be used to control read, delete, update).
A DaDaBIK application must keep the parameter $user_id_group_for_ownership always set to the same value (0 or 1), it is not possible to mix the two different approaches.
insert_date and update_date fields are now insert_date_time and update_date_time fields. If your database field is set as DATE, they register date, if it is set as DATETIME, they register date and time.
DaDaBIK now logs not only the update, delete and insert operations executed but also who (user) has executed them (Enterprise only).
Successful login to the application are now logged into a logs table (Enterprise only). The feature needs to be enabled from config.php (parameter $enable_access_logging).
It is now possible to choose the separator which DaDaBIK uses for displaying several data item related to the same select_multiple_* field. By default it's a line break (as it used to be).
June 24, 2014
Fixed bugs and changes
If you enabled Wordpress authentication, you logged-in (in Wordpress) with User A and then you logged out (from Wordpress), the user was not correctly logged out from DaDaBIK as well and could still access the DaDaBIK application without logging-in until a specific DaDaBIK logout was executed. This was dangerous in particular if you used a shared computer. Furthermore, if you then logged-in in Wordpress using another User B, DaDaBIK didn't update the user logged and his permissions because it still considered User A as the logged user. Fixed.
Please note that 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.
Please note that if you enable 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
The last two issues have been added to the documentation. (unexpected behaviors).
If a field field1 has the edit permission set to "Yes, but disabled" an the edit form, after having clicked on "Save", needed to be showed again because of errors, the value of field1 is not correctly reported in the form.
Setting the edit permissions of a rich_editor field to "yes but disabled" could lead to unexpected results: the field was not disabled and some of the content which follows the field in the page was added to the field content. Fixed.
DaDaBIK now uses the last versions of TinyMCE and htmLawed: 4.1 and 1.1.17; this can fix security problems and other issues that the old TinyMCE and htmLawed versions used could cause.
A new bug has been highlighted in the documentation, know bugs: If an insert/edit form needs to be re-displayed because an error occurred (e.g. a missing required field), file fields don't preserve the values set by the user before submitting the form
It has been highlighted that custom validation functions ARE NOT applied to select_single and select_multiple_ field types.
June 2, 2014
New features and feature changes
The Admin section is now password-protected even if you disable authentication.
Improved Form Configurator: Yes/No radio buttons are now used instead of listboxes, which makes configuration faster.
The permissions manager now allows to save with one click the permission settings related to all the fields in a table.
When you insert a new item for a master/details view, in the insert form the listbox related to master table is now disabled (because it doesn't make sense to change it).
A new option ("treat_blank_as_null", config.php) allows to get rid of the current NULL checkboxes and to 1) Treat empty form fields as NULL values during insert and update 2) View NULL values as empty form fields during edit This, according to the feedback we have received, should make the use of a DaDaBIK application much more friendly to non-technical users.
In a master/details view the alias of the items table is now displayed more clearly and highlighted in details mode as well (not just in edit mode)
The "classic" date and date time field is not supported anymore, the date / datetime picker is now the only option available.
If a select_single or select_multiple field has a "Primary key table" having Browse authorization enabled (or read permissions = MY) and the field is displayed as a "quick search" filter, all the records of the table were displayed and not only the ones inserted by the current user. Fixed.
DaDaBIK corrupted the graphic layout and could in some conditions displayed wrong values for select_multiple_menu and select_multple_checkbox fields in datagrids, details page and CSV when a select_multiple_menu or select_multple_checkbox field value was empty. Fixed.
When using custom formatting functions, DaDaBIK PRO showed in results page wrong values for fields having custom formatting functions: last four characters were cut off and in case of a select_multiple field having several values, no carriage return was displayed between the values. Fixed.
DaDaBIK produced a query execution error if a select_single or select_multiple field has a "Where clause" parameter set and at the same time the "Primary key table" has read permissions set to "My".
When using template, for select_single or select_multiple fields having linked fields, just the last linked field was showed. Fixed.
Quick searches on select_multiple_* fields didn't work correctly and gave wrong results. Fixed. The documentation now also highlights that just a few search operators are compatible with select_multiple_* fields.
DaDaBIK was supposed to produce an error when a search was performed on a date, date_time, insert_date or update_date field using a search operator not compatible but the error didn't show up and the result could be wrong. Fixed.
DaDaBIK, when a CSV was produced, added a carriage return at the end of each cell value. Fixed.
DaDaBIK produced an "undefined variable" error while showing the results grid if a date, date_time, insert_date or update_date field were included in the quick search bar. Fixed. Furthermore, the date_picker search field were always used even if in the configuration file $field_type_for_date was set as "classic".
After having accessed (in edit or details mode) a record with master/details view (master table A, details table B), DaDaBIK showed only the records related to that master record if the details table B was then accessed in "show items" mode. Fixed. This means, however, that now if you perform a search on B, then access (in edit or details mode) a record of the table A, you will then lose the search filter you had on B. This last issue has been added to the documentation as "unexpected behaviour".
DaDaBIK in some cases produced a warning messages if the parameter $field_type_for_date was set to "classic".
Users were supposed to be able to upgrade from DaDaBIK PRO to ENTERPRISE following these instructions:
- Replace all the old files with the new ones (keep your upload folder if you want to save the uploaded files )
- Update your /include/config.php file using your old configuration settings
This upgrade procedure, however, produced a DaDaBIK installation which didn't allow to create PHP custom pages (available since DaDaBIK 6.0). Fixed. It has also been highlighted in documentation that you can upgrade from PRO to ENTERPRISE only if the version is the same (e.g. from 6.1 PRO to 6.1 ENTERPRISE).
If you executed a "DB Synchro" after having changed the name of a field and the field was a primary key, the information about the primary key was not updated in "Table inclusion". Fixed.
In some cases, for DaDaBIK ENTERPRISE, new users (created via DaDaBIK in addition to the default ones) could not log-in because DaDaBIK thought they were LDAP users (even if they were standard DaDaBIK users). In addition, the authentication type field was showed in the insert/edit form while it should not have been (in all versions). This bug was supposed to be fixed but it was not in case of a fresh DaDaBIK installation, now it is completely fixed.
It hase been highlighted that, regardless of the date_format you choose, in edit mode the date in a date picker is always displayed in year-month-day format
select_multiple field types are now better documented in the admin pages.
Fixed some minor issues in the config file.
March 25, 2014
It is now possible to create custom pages running completely custom PHP code, with the only limitation of some variabile naming rules. This is an experimental feature and need to be enabled from config.php setting $enable_custom_php_pages = 1.
The field type select_multiple has been re-introduced, it is now possible to store in a field multiple values (also coming from another table) handling the field by using a multiple select or multiple checkboxes.
An improved engine allows to display record results datagrid faster; you can notice a dramatic improvement when handling tables having millions of records: as an example the time needed to change the results page for a simple table having 8 millions records is now reduced by 74%.
Date and date time fields are now edited using a Jquery Datepicker.
It is now possible to use AND/OR boolean operators for a field during a search, simply typing the operator in the textbox (e.g. "apple OR banana"). The feature must be enabled from config.php ($enable_user_booleans) and by default is disabled.
It is now possible to show a field in the edit form as DISABLED (not editable). To disable a field, set its permissions choosing "yes, but readonly" for the edit permissions.
It is now possible, when setting the "where clause" of a select_single (or select_multiple) field, to write the related SQL also using PHP variables, which will be evaluated at runtime. For example you can create a select_single showing a list of cities (coming from the cities table) and add a filter which depends on the ID of the current user.
When $show_top_buttons is enabled in config-php, the "Back" and "Back to the main table" buttons are now showed also at the top of the form.
DaDaBIK could have problems in handling tables with millions of records, causing the crash of the Web server if the memory was not enough. Fixed. The problem can still arise when using the "previous" or "next" record buttons because DaDaBIK needs to sort the whole table to find previous/next records; for this reason it is now possible to disable the previous/next buttons from config.php.
After an "uninstall table" operation, DaDaBIK deleted the general (granular) permissions related to the table but not the permissions related to each table field; if the table (or a table having the same name) was installed again later, that table got the field permissions that were set for the old one, instead of having all the field permissions set to "NO". Fixed.
The custom formatting functions were not applied individually to linked fields (select_single field type): this bug was supposed to be fixed in version 5.1.2 but it wasn't for DaDaBIK Enterprise. Fixed.
The content type formatting rules were not applied individually to linked fields (select_single field type) for CSV exporting. Fixed.
When adding a new static page, DaDaBIK sometime wrongly detected as possibly duplicated the static page. Fixed.
The upgrade procedure didn't work correctly when a DaDaBIK 5.0 installation needed to be upgraded and the users table name was not the default one (dadabik_users). Fixed.
DaDaBIK produced an error or show empty values in details page if a field had the parameter "Primary key field" set. Fixed.
DaDaBIK could have unexpected results (errors, insertion in the database of the escape character "\" as data, ...) with PostgreSQL and SQLite if magic_quotes_gpc was set to On and magic_quotes_sybase was NOT set to On. Fixed.
In the search form, selecting "is not null" or "is not empty" did not disable the correspondant textbox. Fixed.
In some cases, the previous/next buttons did not bring the user to the correct record, considering the order the records had in the results view. Fixed.
All the operations performed by DaDaBIK on the database are now transactional, which means that it is not possible anymore to end up in an inconsistent state. (E.g. if an operation requires two INSERT statement and the second for some reason does not succeed, the first is also canceled). Please note that on MySQL this requires to set the INNODB engine for all the tables in your database. DaDaBIK can still work with engines different from INNODB as before, but of course the operations will not be transactional.
In the details page, DaDaBIK didn't correctly display the value of a select_single field having value coming from an external table and produced a warning message. Fixed.
DaDaBIK produced an error after a search operation if one of the values inserted in the search form contained the following string ' FROM '. Fixed.
German language is now complete, thanks to Markus Lischer which provided the missing translations.
If, after submitting an edit form, the form itself needed to be showed again (because of one or more errors), files fields seemed to loose their saved values (the values were not lost but were not showed in the form). Fixed.
A new known bug has been included in documentation, explaining that upload and deletion of files are not considered as atomic transactions together with insertion/deletion of records.
DaDaBIK had problems with the upgrade of 4.x releases to 5.x; the upgrade procedure now supports the upgrade starting from version 5.0; versions 4.x, at least at the moment, are not supported anymore.
July 23, 2013
The users page (admin area) has now a direct link to the users page (front-end).
If a web applications/site X, installed in the same domain as a DaDaBIK application Y, used a session variable name that also the dadabik application used, unexpected and risky effects could happen if the application X or another page set a PHPSESSID cookie valid also in the DaDaBIK application path (e.g. valid in the whole domain '/'). For example, if X (which could also be another DaDaBIK application) used the same session variable name to set the current "where clause" for a search, changing the "where clause" in one application could affect the "where clause" in the other. Now a new parameter (dadabik_session_name) is available in config.php in order to avoid this kind of problems.
In some cases, for DaDaBIK ENTERPRISE, new users (created via DaDaBIK in addition to the default ones) could not log-in because DaDaBIK thought they were LDAP users (even if they were standard DaDaBIK users). In addition, the authentication type field was showed in the insert/edit form while it should not have been (in all versions). Fixed.
If a field had the "Primary key field" set in form configurator but it was not a select_single field, DaDaBIK could produce unexpected results. Fixed.
During insert if, for a select_single field without a linked table, a new element was added to the list ("other...") and the value of this element needed escaping (e.g. contained a '), even if the element was already available in the list it was added (resulting in a duplicated item). Fixed.
The custom formatting functions were not applied individually to linked fields (select_single field type). Fixed (not fixed for CSV export, see later).
DaDaBIK did not work correctly and could produce error messages in the following cases:
- Insert or Search in a form having a select_single field whose linked table had read permissions set to MY
- Edit of a record having a select_single field whose linked table had read permissions set to MY and having the selct_single field name different respect to the "Primary key field" parameter of the linked table
DaDaBIK could produce a " Error: during query execution." message with some DBMS configurations when trying to install a table. Fixed.
Page separators did not appear in the details page even if the parameter "Separator before this field (details page)" was set in form configurator. Fixed.
In form configurator, the use of separator for options, linked fields and master/details (~ by default) whose length was more than 1 could lead to unexpected behaviours; now it is not possible anymore to save a separator having a length more than one. The bug has anyway been included in the known bugs for DaDaBIK applications which are already installed.
DaDaBIK Enterprise didn't check if the dbms_type parameter was set in config. Fixed.
Hungarian translation is now complete.
The documentation has been slightly improved.
The content of site_path parameter in config.php has been better clarified.
Instructions about table inclusions have been improved, in particular it has been highlighted that if you want to delete a table from your DB you should first uninstall it in DaDaBIK and then drop it in your DB.
New known bugs
A new known bug has been added to the documentation: the content type formatting rules were not applied individually to linked fields (select_single field type) for CSV exporting. It will be fixed with DaDaBIK 6 because it requires core changes that we are going to apply anyway in DaDaBIK 6.
March 20, 2013
If two DaDaBIK applications were installed under the same domain (e.g. http://mysite.com/dadabik_one/ and http://mysite.com/dadabik_two/) and another page X set a PHPSESSID cookie valid in the whole domain (i.e. having path / ), a user who visited X and login into one of the DaDaBIK application could access the other DaDaBIK application without logging in. X could be for example a normal php page having a session_start() statement.
While this bug is related to a known bug, already documented:
"Malicious users could use PHP scripts for setting session variables to particular values in order to bypass the login procedure and get unauthorized access to DaDaBIK. These scripts must be hosted on the same domain where the DaDaBIK target installation is hosted." the fact that can occur even without the presence of a malicious script made it even worst.
A new parameters ($secret_key) is now available and required in config.php; its value, which must be secret and different for each DaDaBIK application you create, fixes this known bug, including the case explained above.
The Wordpress plugin has also been upgraded and requires to set a $secret_key variable as well (see installation instructions for details).
January 23, 2013
A DaDaBIK application can now be integrated into a Wordpress site through a dedicated wrapper plug-in. Users authenticated through Wordpress can also be automatically authenticated into DaDaBIK too, without doing the log-in again . (Pro and Enterprise version only)
DaDaBIK now supports LDAP authentication (both OpenLDAP and Microsoft Active Directory). LDAP users are also imported in DaDaBIK to allow permissions setting. (Enterprise version only)
Czech language is now available.
A user could delete a record (using an appropriate URL) if he had delete permissions, even if the read permissions were set to MY (owner permissions) and he wasn't the owner of the record. Now, in the same situation, he needed read permissions too for deleting. (Enterprise version only)
After having accessed (in edit/details mode) a record with master/details view, DaDaBIK will show only the records related to that master record if the details table is accessed in "show items" mode. A "remove search filter" is needed to remove the incorrect filter. This was and still is a DaDaBIK known bug; however, version 5 did not show the "remove search filter" link. Fixed. (Pro and Enterprise versions only)
In some cases the parameter "Field present in the search form?" did not appear in the forms configurator. Fixed.
Tooltip content didn't automatically wrap inside the tooltip. Fixed.
When the edit permissions were set to MY (owner permissions) a user which did not own a record couldn't modify it but it could enter into the edit screen (if he had read permissions). Fixed, now he can't enter the edit form anymore. (Enterprise version only)
After log-in, if the username was correct and the password wasn't, a PHP warning message were displayed.
DaDaBIK duplicated the last field of each table in datagrids and forms (BASIC version) or duplicated the search permission entry of the last field of each table for the default group (PRO and ENTERPRISE versions). Fixed.
The configuration file stated that the groups table was used just if $enable_granular_permissions = 1, which was not correct. Fixed, sentence deleted. (ENTERPRISE version only)
DaDaBIK produced, in some specific cases, one or more "Notice: Undefined index: in" notice messages. Fixed.
DaDaBIK produced warning messages and a " Error: it is impossible to run DaDaBIK, probably because you have decided to disable all the tables or the current user doesn't have any permissions set; go to the administration interface and include some tables / set some permissions." message if the logged user changed his own username. Fixed: while the  Error is still displayed, because the current user doesn't have permissions anymore, the PHP warning messages are not displayed anymore.
DaDaBIK could produce a " Error: during query execution" when duplication checking was enabled on table_1, table_1 had a select_single field which linked table_2 and table_2 had a field whose name is equals to table_1's primary key. Fixed.
If a date or date_time dadabik field was hidden from the insert/edit form, during insertion/update DaDaBIK produced some PHP notice messages and the error "You have inserted one or more not valid dates.". Fixed.
With some DBMS configuration, DaDaBIK produced a " Error: during query execution" during installation. Fixed.
In case of error or warning after an insert or update, when the form was re-displayed, a date_time field lost the value for the seconds listbox and DaDaBIK produced a notice PHP message. Fixed.
DaDaBIK didn't show an "Item correctly deleted." message after the deletion of an item in a master/details view. Fixed.
The known bug about master/details view was not explained correctly in the documentation, it affects also accessing a record in details mode, not just edit mode. Documentation fixed.
The documentation "known bugs" section didn't highlight that the "check for duplicate" feature doesn't work not only with file field types but also doesn't work (and produce PHP notice messages) with date, date_time, update_date, insert_date field types and all the fields which are hidden from the insert form. Documentation fixed.
The documentation did not explain how to upgrade from BASIC to PRO/ENTERPRISE or from PRO to ENTERPRISE and in particular did not highlight that it is not possible to move from DaDaBIK BASIC to DaDaBIK PRO/ENTERPRISE keeping the application settings (DaDaBIK must be installed from scratch). Documentation Fixed.
After a DB Synchro -> add fields operation, DaDaBIK lost, for that table, all the form configurator values related to:
- Separators (form dividers)
- Custom validation function
- Custom formatting function
- Custom CSV formatting function
- Where clause
- New line after this field (edit form)?
The configuration file, in the user and group tables section, stated that "You should leave the following 12 parameters as they are...", the parameters were 9 instead. Configuration file fixed.
November 24, 2012
New graphical interface
A completely new permissions manager which allows to set, for each users group, which operations (read, delete, update, create and details) are allowed on each form and field ($enable_granular_permissions in config.php).
PHP hooks: for each form-field it is now possible to write a completely custom PHP validation function (used to validate data during insertion/update) and a completeley custom PHP formatting function (used to format data for datagrid and edit views)
HTML templates for data grids: the sytle of a data grid can be customizable using an HTML template, for example it is now possible to get a google-style results view instead of the classical tabular results data grid very easily just by working on the template.
Filter feature: a quick, customizable, search form a the top of the results data grid.
Static pages: the possibility to add static, custom, pages to the DaDaBIK application (e.g. an help page).
Form design customization: the possibility to choose if a form field has to be positioned close to the previous one in the same form row or in a new one (default behaviour).
It is now possible to insert titled separators between sets of fields in a form.
It is now possible to specify for a field, as a default value, a value coming from a custom SQL query.
DaDaBIK can now, optionally, show a details page of the record just inserted after an insert operation (option show_details_after_insert in config).
DaDaBIK has a new field type: date_time.
It is now possible, for select_single field having data retrieved from another table, to specify a where clause to use while retreiving the data.
In a master/details view, the details table is correctly showed below the corresponding master table record not only when the edit function is used, but also when the details function is used.
The admin section has now an "about/check upgrade" page which shows information about the DaDaBIK installation and check the availability of upgrades.
It is now possible to specify the default value even for a field not present in the insert form
It is now possible to separately choose if a field should be displayed in the insert form or in the edit form.
It is now possible to specify help tooltips for text, textarea and file fields.
DaDaBIK provides now a log feature: INSERT, UPDATE and DELETE operations are optionally logged in a logs table. This can help a data recovery procedure in case of data loss.
If database views (instad of tables) were installed in a DaDaBIK application, DaDaBIK allowed to see the data just in datagrid mode and not in edit/details mode. Now it is possible to use the edit/details too; for views you need to specify the primary key of the table in the admin section.
Tinymce version updated to 3.5.7. This can solve bugs and security issues (if any) caused by the version previously provided.
DaDaBIK's footprint drastically reduced: from 400+ files to 100+ files, total size reduced by about 40%.
Three additional search options are now available: "is different", "is not null" and "is not empty".
The parameter enable_delete_authorization_table, enable_update_authorization_table and enable_browse_authorization_table are not global anymore but can be chosen separately for each table.
It is now possible to have a custom homepage for a DaDaBIK application.
The $ask_confirmation_delete and $edit_target_window parameters now works just with the standard data grid, not with template data grids.
The content type is not taken anymore into consideration for "rich_editor" fields.
For a select_single field, the hard-coded options are not considered anymore if there are also options driven from a table.
For select_single fields, the validation in accordance to content_type is not performed any more.
The field type "password" is not supported anymore, you should convert your "password" fields (if any) to the type "text" before upgrading to DaDaBIK 5
The autosumbit_change_table_control setting in not available any more.
If browse authorization was enabled, users could see just the records they inserted; however, through a select_single which takes the items from another table, all the records were always all visible. Fixed.
The documentation did not mention that, with the "Other choices allowed?" option set to Yes for a select_single field, the "other" value is used to insert a new record in the relative primary key table EVEN IF INSERT OPERATIONS ARE NOT ALLOWED IN THE PRIMARY KEY TABLE. The relative help tooltip now mentions this behavior.
When a user, during an insert or update, chose the "other" option for a select_single field, for the new record inserted in the linked table the id_user-type field (if any) was not filled with the username of the user, so DaDaBIK didn't give the user the ownership of the record. Fixed.
Upgrading from versions before 4.5 pl1 produced an error, bringing to an installation which was just partially upgraded to the last version and leaving some bugs unfixed. Fixed.
Because of some uncaught exceptions in the DaDaBIK PDO abstraction layer, there were some database operations that showed, in case of errors, a PDO back trace which could theoretically reveal some sensible information. Fixed. Please note that, using the official DaDaBIK release code, we are not aware of errors on that operations, but still there is the theoretical possibility of producing errors.
Setting a custom users table / custom users table fields didn't work as expected and could lead to unexpected results. Fixed.
In the Italian translation a sentence had corrupted characters. Fixed.
DaDaBIK showed a (wrong) search results even if the search operators choosen were not compatible with the fields, for example using a contains operator with a date field or a greater_than operator with a select_single field. Fixed, now you can see the list of incompatibilities in the documentation and the user gets an unhandled error message in case an incompatible operator is used.
For a select_single field, mixing hard-coded options and options driven from a table could give unexpected results. Fixed. Now the hard-coded options are not considered if the options are driven from a table.
The parameter $dadabik_main_file was not used in two links, where the file name index.php was hard-coded.
Table $table_list_name, which was supposed to follow other tables rules about naming (just the prefix must be changeable from config.php) , was still entirely changable. Fixed, it is now highlighted that the name must be kept as it is.
Setting $autosumbit_change_table_control = 0 produced a "Notice: Undefined variable: submit_buttons_ar" message. The $autosumbit_change_table_control is not available any more.
DaDaBIK produced a PHP notice message if a image_file or generic_file field was SET as NULL during insert or update. Fixed.
The "literal_english" date format displayed the date in a "day month year" format instead of "month day, year". Fixed.
On some combinations of PHP version/Operating System DaDaBIK could produce an error during the MySQL connection. Fixed.
While it was explained in the "Known bugs, limitations and unexpected behaviors" documentation section, the upgrade script did not explicit said that the upgrade does not work correctly with SQLite; a DaDaBIK upgrade using SQLite could bring to unexpected behavior. Now the upgrade script prevent the use with SQLite.
November 3, 2012
Fixed bugs and other changes
The documentation section about multiple instances of DaDaBIK has been (at least for the moment) removed. That section was not up-to-date and referred to a version of DaDaBIK which still didn't have the authentication feature: the result is that if users followed those instructions having authentication ON, a user authenticated on the first (not admin) instance could also access the /admin instance without authentication. This is not a proper bug but could lead to a false sense of security.
Most of the language translations got corrupted after the 4.6 beta utf-8 move. Fixed.
DaDaBIK could silently truncate some of the parameters values in interface configurator if the lenght of the parameter value length was greater than a threshold which depended on the parameter itself. Fixed.
Prefix and defaut values didn't work correclty if they contained a double quote character. Fixed.
The amount of time before a record is automatically unlocked is now 4 minutes (it was 2).
Authentication is now enabled by default.
The Russian language was not specified in the languages list to choose from (config.php). Fixed.
A re-installation of DaDaBIK on the same database didn't clean-up the table containing the information about the installation itself. Fixed. This bug shouldn't have had any effect on the user side, though.
The importance of the parameter $site_path for security reasons has been highlighted in config.php.
The authentication section of the Documentation was not clear. Improved.
Due to SQLite limitations, the script for upgrading DaDaBIK to a new release is not anymore available for SQLite.
The following fix was implemented in 4.6 beta but the quotes in the sentences appeared corrupted in the change log, so re-post: Table or field names having the string "from" in the name could lead to query execution error with SQLite. Fixed.
The following fix was implemented in 4.6 beta but didn't appear in the change log, so re-post: The installation of views diddn't work with MySQL and PostgreSQL. Fixed.
September 27, 2012
v. 4.6 beta
New feature/fixed bug
DaDaBIK now officially supports UTF-8, allowing the correct handling of content in almost any known language and writing system. While some hacks for adding UTF-8 support have been posted on the forum during the last years, this feature has never been officially introduced because of the drawbacks involved: PHP doesn't offer a complete support for multibyte encoding and using DaDaBIK with UTF-8 content could lead to unexpected and bad results such as content corruption. The new version of DaDaBIK has been completely revised in order to work well with UTF-8 content; there are still some cases in which the correct handling of UTF-8 is not guaranteed, see Documentation-> Known bugs, limitations and unexpected behaviors for further details.
Fixed bugs and other changes
DaDaBIK does not use the ADOdb library anymore for MySQL and PostgreSQL. It just uses the PHP PDO extension, as already did for SQLite.
The new requirements are: PHP >= 5.1 with the mbstring extension enabled and one of the following: MySQL >= 5.0 or PostgreSQL >= 7.4 or SQLite >= 3. The database default charset must be UTF-8 if you need to handle UTF-8 content.
DaDaBIK now uses the last version of HTMLawed, which fixes several bugs affecting the version in use before, for improved security while using the HTML content type or the rich editor field type.
With SQLite, because of some uncaught exceptions, there were some queries that showed, in case of errors, a PDO back trace which revealed some information e.g. the path of the PHP file or the query itself. Fixed. Please note that, due to the nature of the queries involved, it should have been difficult, for a malicious user, to intentionally cause the queries to fail in order to display those information.
While the documentation said that quote characters can lead to problems if used in table and field names, also all the characters which need to be escaped such as ' ` " \ can lead to the same problems, documentation updated.
DaDaBIK didn't create interfaces on views if used with SQLite. Fixed.
A date, insert_date or update_date field having just one search operator prevented the display of a "blank option" in the search operators listbox. This means that it wasn't possible to perform a search without considering such a field, if it was in a form. Fixed.
Table or field names having the string “from” in the name could lead to query execution error with SQLite. Fixed.
Registering a new user having a username or password which contained characters which needed to be escaped (e.g. ') was not possible. Fixed.
The check about the max length of a field value didn't work correctly if the user inserted a value containing a character which needed to be quoted (e.g. '). Fixed.
If a field had a prefix, the check about the field type (e.g. email checking), which was supposed not to be performed if the user just left the field as it was (filled by the prefix) during an insert/upate, was instead performed on the prefix if the prefix contained a character wchich needed to be quoted (e.g. '). Fixed.
If a field had a prefix, the "check for duplicated" and "check requried" feature didn't work correctly if the prefix contained a character wchich needed to be quoted (e.g. '). Fixed.
If a field had a prefix and the user just left the field as it was (filled by the prefix) during an insert/upate, DaDaBIK inserted in the database the prefix instead of a blank value if the prefix contained a character wchich needed to be quoted (e.g. '). Fixed.
The "check for duplicated" feature didn't work correctly if the user filled one of the field to check with a value containing a character which needed to be quoted (e.g. '). Fixed.
The check type (email, url,...) feature could (should be very unlikely) not to work correctly if the user filled the field to check with a value containing a character which needed to be quoted (e.g. '). Fixed.
A select_single field having options set by hand and allowing the choice of additional options added the additional options to the list of the options even if tis was already existent (creating a duplicate) if the option contained a character which needed to be quoted (e.g. '). Fixed.
A master details view didn't show the items record related to the master record and didn't allow to create new items if the primary key field value of the master record contained a character which needed to be quoted (e.g. '). Fixed.
A primary key containing as value a character which needed to be quoted (e.g. ') could lead to unexpected results. Fixed.
If the master/details feature was used, a primary key field name of the master table or its value containing a character which needed to be url-encoded to be passed via querystring (i.e. all non-alphanumeric characters except -_.) could lead to unexpected results. Fixed. Remember that table and field names still have restrictions (see the documentation, known bugs).
A table name containing a character which needed to be url-encoded to be passed via querystring (i.e. all non-alphanumeric characters except -_.) could lead to unexpected results. Fixed. Remember that table and field names still have restrictions (see the documentation, known bugs).
The table menu in the front-end is now always ordered by the table alias.
Some outdated parts of the documentation has been removed.
The setting $enable_word_wrap_cut is no longer available.
August 15, 2012
v. 4.5 patch level 1 (pl1)
DaDaBIK used to store users' passwords using the encryption provided by md5(). While this approach allows for a first level of security, because passwords are not stored in clear text into the database, it does not prevent some type of attacks which a malicious user can do after having obtained the encrypted passwords, such as attacks based on pre-hashed lists or rainbow tables.
For this reason, DaDaBIK, as other popular Web applications such as WordPress did, moves to phpass for managing the password storage. phpass is a framework which supports three password hashing methods (CRYPT_BLOWFISH, CRYPT_EXT_DES and an md5-based method) and chooses the best one according to what the current system can provide. All three employ salting, stretching, and variable iteration counts. This change makes the attacks much more difficult to be successfully executed.
DaDaBIK didn't work correctly and produced a " Error: during query execution" if, for a select_single field, the user tried to select the "other" option. Fixed.
The default language was set to Estonian instead of English. Fixed.
A "unexpected behaviour" about search and formatting tags, which was supposed to be added to the documentation, wasn't actually addedd. Fixed.
June 25, 2012
In some cases you could get a "Specified key was too long; max key length is 1000 bytes" or similar error during installation. Fixed. Thanks to Alonzo for having reported it. Furthermore, in some cases (probably quite uncommon), where a table name or its unique field name or a unique field record value are longer than expected, the record locking feature could work not correctly. Now DaDaBIK produces an error if the lenght is not supported.
Using the rich_editor field type led to incorrect search results because the HTML editor add fomatting tags by default to the search text. Now a normal textearea is used for search forms to avoid this behavior. Thanks to user Funbird for the report. Please note that, still, the formatting tags inserted in a field through the HTML editor are not filtered so if you search "hey good" and you have "hey good morning" in your DB, of course you won't find it. This has been added to the "unexpected behaviors" section of the documentation.
The "refresh installation" operation lost settings about master/details views: table and linked items. Fixed.
DaDaBIK had a typo in the German translation. Fixed. (Thanks Heinz for the report)
A bug about the default date 1968-01-01 was listed in the "Known bugs" documentation section even if it was already solved. Fixed.
Choosing Estonian as language led to a parse error message. Fixed.
During installation, a warning message is now displayed about the risks of enabling the CSV export feature in a public site. A note in the documentation has also been added. Thanks to user dh for having reported it.
A minor bug about record editing when an identifier field value is changed has been added to the known bugs section of the documentation.
May 31, 2012
v. 4.5 beta
DaDaBIK now provides a complete record-locking mechanism. When a user U1 enter a record in edit mode, the record is locked and other users can't modify it. The record is unlocked if the user U1 exit the edit mode or after a certain amount of time (configurable in config.php). The feature still work even if two users log into the system using the same username and even if authentication is disabled.
The new feature allows DaDaBIK to avoid unexpected data overwriting: for example imagine user A and user B opening in edit mode the same record about a product. Both the users modify the price, user A from 50 euros to 60 euros, user B from 50 euros to 70 euros. Imagine that user B clicks on the save button a few seconds after user A. Both the users would think to have correctly modify the price, but user A is wrong, the current price is now 70 euros. Another example: user A modify the price, user B the description; in this case user B overrides the price modifications made by user A, the price is therefore restored to its initial value.
DaDaBIK now uses just one internal table to keep all the information about the form settings. Previous versions used one internal table for each form, which resulted in some cases in an annoying number of items per database.
A unique upgrade script (upgrade.php) is now available to upgrade to the last version from any version >= 4.3 final. DaDaBIK can now recognize the version you have installed and if it's >= 4.3 final, upgrade it to the last version.
DaDaBIK now uses the last versions of ADOdb, TinyMCE and htmLawed: 5.15, 3.5.11 and 1.1.10; this can fix SECURITY problems and other issues that the old ADOdb, TinyMCE and htmLawed versions used could cause. The very last version of ADOdb is actually 5.17 but since we experienced problems with PostgreSQL using 5.16 and 5.17 we chose to include version 5.15.
Insertion of a record could work not correctly and produce an error if there was an id_user field type and the username of the user contained characters which needed to be escaped (e.g. '). Fixed.
DaDaBIK could work not correctly and produce errors with PostgreSQL and SQLite in the following cases:
1) the username of the user contained characters which needed to be escaped (e.g. ').
2) during a "refresh installation" procedure
3) insert/update of a record, select_single field type, if the user chose "other" and the previous listbox values or the new one contained characters which needed to be escaped (e.g. ')
4) insert/update of a record, generic_file/image_file field type, if the filename contained characters which needed to be escaped (e.g. ')
The DaDaBIK installation procedure, if there was a pre-existent table called users_tab in the database where DaDaBIK was installed, overwrote that table. This behaviour is now highlighted in the installation page.
With $debug_mode set to 1 and SQLite, the SQL statement was not showed in case of error, as it was supposed to be. Fixed.
DaDaBIK could produce a PHP Strict Standards message during installation. Fixed.
For consistency with other configuration parameters, you cannot anymore change the $table_list_name but only its prefix, furthermore in the configuration file it has been highlighted, for the sake of clarity, that the users table doesn't use the table prefix (dadabik_ by default) as the other ones.
DaDaBIK produced an error and failed the installation procedure on PostgreSQL in case of re-installation over a pre-existing installation. Both the re-installation of a single table and the complete re-installation gave the same results. Fixed.
On SQLite, DaDaBIK creates by default an interface also for the table sqlite_sequence, which is not a table managed by users but a system table. Fixed.
DaDaBIK produced an error if, from the admin interface, a user tried to re-install the users table. Fixed.
DaDaBIK is now licensed under the DaDaBIK license.
May 5, 2012
v. 4.4 patch level 1
DaDaBIK produced an error, if used with PostgreSQL or SQLite, when a search produced more than one results page and the user clicked on one of the pages. The problem could affect MySQL just in some cases. Fixed.
Due to a non correct un-escape process of escaped characters, insert/update of wrong data in the database were possible. Fixed. DaDaBIK had the wrong HTML generator tag. Fixed.
Postgresql <= 6.4 is no more supported.
April 3, 2012
New features and feature changes
DaDaBIK can now officially handle and create front-end for views, in addition to front-end for normal tables. This can help in creating more flexible database applications.
It is now possible to avoid the display of the NULL column in the insert/edit form. A parameter $null_checkbox is now available in config.php. Note that, if the record you are editing contains a NULL value for one or more fields, the NULL checkboxes are displayed anyway, even if $null_checkbox is set to 0.
The DaDaBIK end-user interface is now available in Russian.
Oracle and MS SQL Server are not officially supported anymore.
German, Dutch and French translations are now complete.
Some special characters were not correctly escaped in some situations, this chould lead to errors and/or insert/update of wrong data in the database.
DaDaBIK, with SQLite, didn't produce error messages if an SQL query failed. For example, an insert query which violated a constrain, was reported as "Record correctly inserted." even if the record was not inserted. Fixed.
DaDaBIK produced a "Fatal error: Cannot re-assign auto-global variable _POST" if used together with PHP 4.4. Fixed.
DaDaBIK produced an error during installation with PostgreSQL >= 9.1. Fixed.
If all the fields of an edit form were required but one or more fields were NULL in the database, the corresponding NULL checkbox were displayed but the column label "NULL" were not. Fixed, the column label is now displayed.
A bug prevented to work correctly with date type field and SQLite. Fixed. Thanks to Triton for having reported it (http://www.dadabik.org/forum/read.php?1,14771).
If, for a date field, the value of the month was set to other than [1-12] OR the value of the day was set to other than [1-31] OR the value of the year was set to other than [$start_year-$end_year] DaDaBIK will displayed in the edit view, for the relative field, the first default value available in the listbox. For example if a date field was set 1940-00-00 in the database, DaDaBIK will display, in its default configuration, 1968-01-01 and updated the date to 1968-01-01 if the record is saved. Fixed. Now DaDaBIK produce an error message if a date value is not representable with the day-month-year listboxes.
If, for a select_single field, the user selected "other" and didn't specify a custom value during insert/update, the value "......" was inserted. Fixed, now a "required field" error message is displayed.
If, after a insert/update operation, the form was displayed again to the user because of an error (e.g. a required field was not filled) and the value of a date field was set to NULL, some undefined variable messages were displayed. Fixed.
If, for a select_single field, the user selected "other" and specify a custom value during insert, that new value was not included as additional option. Fixed.
A new section, "Unexpected behaviors" has been added to the documentation. It's a list of behaviors which the average user doesn't expect from DaDaBIK but that probably can't be considered real bugs. An important point discussed here is about 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.
The "Known bugs and limitations" section of the documentation has been updated, highlighting two bugs, one related to search operations and the other related to some characters which, for some languages, are incorrectly displayed.
February 14, 2012
v. 4.4 beta
The authentication didn't work correctly and prevent users to log-in if the DBMS chosen was SQLite. FIXED.
The date field type didn't work properly during insert/update/search and produced a "Notice: Undefined property" message. FIXED.
Master/details view didn't work correctly with SQLite and produced a "Call to undefined method PDOStatement::MoveFirst()" message. FIXED.
When a new item was inserted in a master-details view, the default "parent" item wasn't selected if the field name of the parent table and the (fk) field name of the items table were different. FIXED.
The "Known bugs and limitations" section of the documentation has been updated, highlighting a new date-field related bug; the lack of a locking mechanism during records editing has also been highlighted in the documentation, since the current behaviour could lead to unexpected results and data loss.
February 2, 2011
v. 4.4 alpha
New features and feature changes
DaDaBIK now supports SQLite
A new content type "timestamp" is available. The corresponding field must contain an integer, which is displayed as a date and time according to the format chosen with the paramenter $date_format.
magic_quotes_sybase = on in php.ini is no longer required for Oracle and MS SQL Server
The documentation is now more clear about the master/details view.
A new parameter, $timezone, allows to set the timezone.
The sql logging feature is not available anymore.
The authentication didn't work if DaDaBIK was installed in the root of a Website (e.g. www.mysite.com and not www.mysite.com/dadabik).
DaDaBIK produced an error about date_default_timezone_set if the PHP version was < 5.1.
December 8, 2010
v. 4.3 final
Fixed bugs and feature changes
The TinyMCE version used to implement the rich_editor is now the 126.96.36.199 . This can fix security problems and other issues that the old TinyMCE version used could cause.
Some MAC OS not needed files were included in the DaDaBIK release. Fixed (thanks Tobias S. for pointing out).
On Windows Vista (and maybe on other Operating Systems), some warnings about encoding were displayed by the system during the extraction of the zip release file. Fixed (thanks Tobias S. for pointing out).
DaDaBIK showed a "delete all" link for an items table even if the delete operation was disabled for that table. The "delete all" operation, however, wasn't executed. Fixed.
After a "delete all" operation performed on a master/details view, DaDaBIK showed the results view of the details table instead of coming back to the master/details view. Fixed.
DaDaBIK now shows a table alias near to the "insert item" link.
Minor change to the English interface
A small banner is now showed in the homepage of the admin interface.
The changelog didn't contain the changes for DaDaBIK 4.3 beta. Fixed.
November 28, 2010
v. 4.3 beta RC2 (release candidate 2)
New features, fixed bugs and feature changes
DaDaBIK, with some PHP versions and error reporting settings, produced some "Deprecated" and "Strict Standard" warnings. This was due to the ADOdb version used, which was too old. DaDaBIK now uses the last ADOdb version for PHP5 and automatically load the last PHP4 compatible ADOdb library if you are still using PHP4. This can also fix security problems and other issues that the old ADOdb version used could cause.
The single-donation button of the admin section didn't work.
A lot of not strictly-needed files has been removed from the official release, which is now lighter.
It is now possible to to send feedback on DaDaBIK to hotscripts.com directly from the admin section.
The documentation didn't explain how to upgrade to 4.3 rc1. Fixed.
November 23, 2010
v. 4.3 beta RC1 (release candidate 1)
New features and feature changes
DaDaBIK has a new administration section: new look, some improvements in the interface, in-line help for the interface configurator, possibility to send feedback, to donate and to buy email/phone commercial support. The configuration file has been improved in clarity too.
It is now possible to choose if a table can appear in the table list menu.
The "home" button, which had been deleted, is now available again.
If a table is an "items table" in a master-details view, the insert/search/show all/last search results top buttons are not anymore displayed,
The documentation has been completely revised, clarifying some aspects when needed and highlighting some new known bugs/limitations.
Minor GUI enanchements.
DaDaBIK 4.3 beta3 in a case-sensitive environment didn't include the htmLawed library because of a mistake in the case of a letter. This leave DaDaBIK exposed to the security risk that version 4.3 beta3 was supposed to fix (see 4.3 beta 3 changelog's entry for details). A "Warning: include(./include/htmlawed/htmlawed.php) : failed to open stream" warning messase could also be produced. Thanks to Kaiya for pointing this out.
With PHP < 4.1.0 and DaDaBIK 4.3 beta, beta2 or beta3 there could be problems with the escaping procedure, this could lead to various problems (even security problems).
The URL validation didn't work as expected.
The enable/disable features control didn't work as expected.
If the first table present in the table list menu was empty (no records), DaDaBIK didn't show the table list menu.
When $enable_browse_authorization was enabled, using the previous-next links DaDaBIK tried to show also non-authorized records; the records details weren't showed but a message "You don't have the authorization to view this record." was displayed.
DaDaBIK, if a table was used as "items" table, didn't correctly take into consideration the permissions (insert, edit, details, delete) set in order to display the corresponding controls.
When a record is deleted, now also the files linked to the record are deleted. Is it possible to control this behaviour changing the new config parameters delete_files_when_delete_record.
November 15, 2010
v. 4.3 beta3
Fixed bugs and changes
Since htmLawed requires at least PHP version 4.3, even the PHP minimum version requirements of DaDaBIK have changed from 4.05 to 4.3.
November 11, 2010
v. 4.3 beta2
The problems described above can occur even when the insert or edit feature was enabled (at least for one table) and the HTML content type is used; at the moment there isn't a patch for this second scenario, the HTML content type should be used carefully, as highlighted in the upgraded documentation.
DaDaBIK didn't show the default edit, delete and delete icons.
October 21, 2010
v. 4.3 beta
New features and feature changes
DaDaBIK has now a new and better Graphic User Interface.
Having magic_quotes_gpc set to On is not anymore needed.
The documentation, in particular the "Known bugs and limitations" sections, has been updated.
DaDaBIK showed a notice error message when the previous/next button was used after an error on update (e.g. a missing field); now the buttons are not anymore displayed.
DaDaBIK produced a "Undefined variable" notice when showing results and nor records were found.
DaDaBIK could display a deprecated warning related to eregi if used together with PHP >= 5.3
The upgrade file upgrade_4.3.php was not adodb-compatible and therefore probably didn't work with all the DBMS supported.
September 14, 2010
v. 4.3 alpha
New features and feature changes
DaDaBIK now supports a master/details view: for example if you have an albums table and a songs table you can set DaDaBIK to display in the same page the details of an album and the result list of the songs linked to.
The documentation, in particular the "Security" and "Multiple function views" sections, have been updated.
DaDaBIK didn't correctly execute a search based on a field if, for that field, you choosed from the interface configurator just one search operator.
February 18, 2007
The Rumanian language is now complete.
February 8, 2007
v. 4.2 beta
Previous and next buttons didn't work correctly after an update operation which caused an error (for example for a missed required field value) and now are not displayed any more in the above case.
New features and feature changes
DaDaBIK now handles the NULL values, it is now possible to insert a NULL value in a field and to search for NULL values.
New search operator available: is empty.
The required fields are now displayed using a * sign, instead of using a different color.
The documentation, in particular the "Known bugs and limitations" section, has been updated.
January 18, 2007
v. 4.1 final release
After a login or a "Show all" operation the order type stored for the current table was not cleaned, as expected.
In some particular cases, the previous and next record links didn't work and DaDaBIK produced a "Notice: Undefined index:..." message.
For a linked field, DaDaBIK didn't use its own type and content in order to correctly display it in the results and details view.
January 14, 2007
v. 4.1 release candidate 3
DaDaBIK version 4.1 rc2 produced a " Error: during query execution." error message during the installation.
January 14, 2007
v. 4.1 release candidate 2
The "refresh installation" admin operation didn't work correctly and could lead to an interface configurator settings loss. Please note that this bug can appear even on a DaDaBIK version >= 4.1 rc2 if the installation is the result of an upgrade from a version < 4.1 rc2; the 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.
DaDaBIK in some cases produced an " Error: during query execution." error message if the user clicked on the previous or next record links.
DaDaBIK lost the "Field present in the details page?" option setting after a "Refresh installation" procedure.
Rumanian language is now complete.
Some CSS style settings were repeated twice in css/styles_screen.css, in some cases using different values.
The documentation has been revisited, in particular the upgrade process is now clearer and a new known bug has been added to the documentation.
If one or more tables name were particularly long DaDaBIK could produce a " Error: during query execution." error message on Oracle during the DaDaBIK installation or during a single table installation.
The default upper limit for the year part of a date is now 2010.
styles_print.css code clean-up.
New features and feature changes
The pdf file extension is now allowed by default for file upload.
November 13, 2006
v. 4.1 release candidate 1
If a table was empty and the user selected it, the tables listbox disappeared so it was impossible to choose another table.
The upgrade script upgrade_4.1.php had the name of one of the DaDaBIK tables hard-coded; this could lead to problems during the upgrade process if the $table_list_name (confgi.php) variable value was not "dadabik_table_list".
The upgrade script upgrade_4.1.php didn't work correctly on Oracle.
Portuguese language is now complete.
Croatian language is now complete.
Swedish language was not present in the documentation languages list.
October 24, 2006
v. 4.1 beta
New features and feature changes
Better form errors handling: if an error occurs when the user fills a form (e.g. an URL format is not correct), DaDaBIK will display again the form and point out the type of error.
E-mail notices: DaDaBIK sends an e-mail message to some specified people when a new record is inserted or an existent record modified.
Previous and next buttons are now available in edit and details views.
Also the administration pages are now protected by authentication (if enabled); only administrator users can enter the administration pages. Note that the installation file (install.php) is not protected, should be used only for the first installation and then removed.
DaDaBIK now remembers the last search executed on a table, even if you change table.
It is now possible to choose the number of result records displayed per page on the fly. DaDaBIK also saves the number choosed on a per-table base.
It is now possible to set an alias for each table, the alias is used in the table listbox instead of the table name.
DaDaBIK now uses tinymce 2.0.7 (http://tinymce.moxiecode.com) to implement the rich_editor field type instead of htmlarea. This leads to FireFox compatibily.
DaDaBIK now highlights a results table row when the mouse pointer is over it. It also highlights a results table row when the user click on it, until the user click it again. You can disable this feature by using the new config.php parameter $enable_row_highlighting.
Some changes in the layout element positions to increase usability.
Finnish language is now available.
A link to the administration page is now available and is displayed only if the user is an administrator.
DaDaBIK now display using a small arrow the current type of order (ASC or DESC).
By default, after an insert is now displayed the results view.
During an insert, even if authentication and browse authorization were enabled, the similarity check procedure checked not only the records that the curent user owned, but all the records and showed the possible duplicates even if the current user didn't own them.
The documentation has been revisited, in particular it has been highlighted that Oracle needs magic_quotes_sybase = on set in php.ini.
October 04, 2006
DaDaBIK now uses ADOdb version 4.92. This change fixes the "Notice: Only variable references should be returned by reference in..." messages.
Swedish language is now available
DaDaBIK installation process on Oracle is now clearer.
On Oracle, from the record results view, several "Undefined index" notices were displayed, it was not possible to correctly enter the detail and the edit form of the records and the delete record function didn't work.
On Oracle 10, DaDaBIK tried to use the recycle bin tables too.
The documentation has been revisited.
In the install.php and header_admin.php scripts the name of the file index.php was hard-coded, instead of varying according to the $dadabik_main_file config variable.
The configuration file is now clearer about the $host parameter and specify the possible need of the instance name for MS SQL server
January 24, 2006
v. 4.0 beta 2
There was some missing information in the documentation.
January 24, 2006
v. 4.0 beta
DaDaBIK officially supports Oracle and MS SQL Server DBMS. A special thanks to Claude Moreau (claude dot moreau dot olom at gmail dot com) for the great work he did on the Oracle porting.
The Hungarian and Slovak languages are now available.
The documentation has been improved and a new section "Coding guidelines" has been added.
DaDaBIK now checks for duplications by default for the username field of the users table.
It is now possible to set the CSV creation time limit; this can fix the problems related to the CSV creation time limit errors.
Two DaDaBIK buttons are now available ("buttons" folder).
DaDaBIK didn't display correct search result values when the same field name appears in two linked tables as linked field. This bug, supposed to be fixed in the 3.1 beta release, is now really fixed.
DaDaBIK showed a wrong list of result records for a search if $enable_authentication and $enable_browse_authorization were enabled and the user specified more than one search criteria, setting also "Any of the conditions required".
The required property didn't work properly with file types, now the setting of a file-type field as "not required" is not needed any more. Thanks to alpha2zee (drpatnaik at yahoo dot com) who proposed the first version of the patch.
DaDaBIK produced a "Fatal error: Call to undefined function: newadoconnection()" message if upgrade.php or upgrade_3.2.php were executed.
DaDaBIK produced a "Notice: Undefined variable: upgrade...." message when upgrade.php was executed.
In the login.php script the name of the file index.php was hard-coded, instead of varying according to the $dadabik_main_file config variable.
DaDaBIK didn't display the "create password" after a user adding if $insert_again_after_insert was set to 1.
DaDaBIK displayed some messages in English even if the language set was "Italian".
June 20, 2005
v. 4.0 alpha
DaDaBIK produced some "Notice: Undefined variable....." messages and a " Error: during query execution" error message in the details or edit view (if $enable_browse_authorization was enabled) or after a delete (if $enable_delete_authorization was enabled) or update (if $enable_update_authorization was enabled); only if $enable_authentication was enabled and the current table or the ID_user field name needed to be quoted.
DaDaBIK uses now the ADOdb Database Abstraction Library in order to support as many DBMS as possible, at the moment it has been tested just with MySQL 4.0.x and PostgreSQL 8.x.
SQL logging: it is now possible to configure DaDaBIK for logging all SQL queries in the adodb_logsql table ($enable_sql_logging parameter in config.php)
The documentation has been revised.
June 4, 2005
If two or more DaDaBIK installations were hosted under the same domain, if a user logged into one of them it was possible to access all the others bypassing the login procedure. DaDaBIK session cookies are now valid only for the directory where DaDaBIK is installed (set through the new configuration variable $site_path).
DaDaBIK produced a parse error if the Portuguese language was used.
Croatian translation is now complete.
DaDaBIK produced a " Error: during query execution" error message in the results view if the table in use or the current "order by" field name needed to be quoted and the current "order by" field hadn't any linked fields.
The possible duplications results view didn't show linked field values and produced a "Notice: Undefined index....." error message if one ore more fields had linked fields (http://www.dadabik.org/forum/read.php?f=1&i=4302&t=4154).
Added two known bugs to the documentation, in particular it has been highlighted a possible security problem of the DaDaBIK authentication model.
March 31, 2005
v. 3.2 beta
DaDaBIK produced a " Error: during query execution" error message in the details view if, for a field, the primary key field name of the main table was the same of the primary key field name of the linked table.
All the "Undefined variable" error messages have been fixed, DaDaBIK can now works correctly with error_reporting = E_ALL.
DaDaBIK lost the "Other choices allowed?" option information after a "Refresh installation" procedure (administration interface).
DaDaBIK produced a " Error: during query execution" error message if, during an insert or update, a new option was added to a select_single field with no linked fields and at least one of the preexisting options contained a character to be escaped (e.g. ').
DaDaBIK produced a " Error: during query execution" error message if, during an insert or update, there was at least one select_single field with linked fields, $enable_authentication and $enable_browse_authorization were enabled, the table contains an ID_user field and the linked table doesn't contain any ID_user fields with the same field name.
An Italian sentence was not correct.
DaDaBIK produced a parse error message if the German language was used
In the footer page the name of the file index.php was hard-coded, instead of varying according to the $dadabik_main_file config variable.
Config variable $always_add_blank_option_search didn't work correctly, the variable is not used any more and now DaDaBIK always add a blank option to the select_single fields.
New features and feature changes
The authentication code has been in part rewritten:
- The class simpleLogin (http://www.phpclasses.org/browse/package/1492.html) is not used any more
- DaDaBIK stores now user information in the database and passwords are now md5 encrypted
- It is also possible to use a pre-existent users table
- You can use DaDaBIK itself in order to add and delete users, show and modify users information
- The admin pages (admin.php, install.php) are not login-protected any more, you have to provide your own protection
- A select_single field with linked fields now shows a listbox with all the corresponding linked table records, regardless of the ownership.
A "top" link has been added to the HTML footer.
The documentation has been updated and improved, in particular a FAQ section is now available.
The installation procedure has now more explicative messages.
July 19, 2004
v. 3.1 beta
DaDaBIK produced a " Error: during query execution" when a linked table was referenced more than once in the same table.
DaDaBIK didn't display correct result values when the same field name appears both in a table and in a linked table as linked field or in two linked tables as linked field.
DaDaBIK has now a rewritten engine that perform the select query using joins and aliases (this fixes the bug above)
A basic authorization model is available, it is now possible to allow a user to delete only his own records, modify only his own records, view only his own records. For the authentication the class simpleLogin (http://www.phpclasses.org/browse/package/1492.html) has been (probably temporary) used, but it is possible to easily customize the authentication.
A new field type is available: rich_editor; it is a rich text editor (htmlArea 2.03 by interactivetools.com http://www.interactivetools.com/products/htmlarea/) that allows to easily insert/modify HTML content
A new content type is available: html, DaDaBIK doesn't perform a conversion from special characters to HTML entities with htmlspecialchars for the fields having this content type
DaDaBIK starts now displaying the records of the first table available, without showing the home page menu. All the application (except from the administration area) uses now just one file index.php, easily renameable to embed it in a pre-existent Web site.
An upgrade script is now available, it is possible to upgrade from 3.0 beta or 3.0 to 3.1 beta without loosing the interface configurator settings.
A new parameter $enable_delete_all_feature allows to enable/disable the delete all feature
May 25, 2004
DaDaBIK produced a " Error: during query execution" error when a table name contained blank spaces (http://www.dadabik.org/forum/read.php?f=1&i=2136&t=2136).
DaDaBIK produced a " Error: during query execution" error when the MySQL version was prior to 3.23.06.
DaDaBIK produced a " Error: during query execution" error when a field has some linked fields associated and the primary key field is not numeric (http://www.dadabik.org/forum/read.php?f=1&i=2365&t=2365).
DaDaBIK produced a "Call to undefined function: ob_clean()...." fatal error if the export to CSV feature was enabled and the PHP version was < 4.2.0 (http://www.dadabik.org/forum/read.php?f=1&i=2329&t=2209); the export to CSV now works also with PHP version prior to 4.2.0.
DaDaBIK produced a parse error when the Italian language was used.
Fixed some translations and added a missing sentence in the Italian language file.
The word "home" in the bottom links menu is now available in each language file and no more hard-coded.
DaDaBIK produced a "Undefined variable: mail_feature....." notice.
A new parameter $word_wrap_fix_width allows to choose if $word_wrap_col determines also the width of the column in the results table or not.
The following two bugs have been discovered during the beta testing:
DaDaBIK produces a " Error: during query execution" when a linked table is referenced more than once in the same table (http://www.dadabik.org/forum/read.php?f=1&i=2374&t=2374).
DaDaBIK doesn't display correct result values when the same field name appears both in a table and in a linked table as linked field or in two linked tables as linked field.
These bugs will be fixed in the version 3.1 because they require to partially rewrite the engine that produce the SELECT statement.
March 10, 2004
v. 3.0 Beta
All the code has been revisited and in some case rewritten in order to increase efficiency and clarity.
New features and feature changes
The primary-foreign key feature is now complete: it is possible to link a field of a table (foreign key) to a number of fields of another table (containing the primary key). The produced HTML select menu will have the linked field values as "options" and the primary key values as "values". This allow to use a normalized db design.
The "export to CSV" feature has been added: it is now possible to export the current result records to a CSV file.
The speed of DaDaBIK when the database managed contains a lot of tables is now dramatically increased.
"Delete all" feature is now available: it is possible to delete all the current result records.
It is now possible to handle all the HTML produced by DaDaBIK by the CSS file, which is now very clear and complete, a new CSS file specific for printing has been also added.
It is now possible to order result records both in ASC and DESC.
The HTML produced by DaDaBIK is now more clean and complete than before.
If no order field is specified, the result records are displayed ordered by the first field present in the results table.
Two new select operators have been added: "starts with" and "ends with"
After a delete operation DaDaBIK now display again the results page.
The alternate row colors feature is now available. The record results table is now displayed using alternate row colors.
When you save a record, now the edit form is displayed again on the screen.
When you insert a new record, you can now choose (through config.php) if you want to see again the insert form, otherwise the results table is again displayed.
Edit, delete and details buttons are now normal links (not HTML forms as before) and pass all the necessary values via GET, so it is now possible to call the detail page of a record from its own unique URL.
Documentation, administration interface and config.php file are now more clear and complete than before.
Each DaDaBIK error message has now a code, in order to identify it better, especially during bug reports.
DaDaBIK messages are now displayed everywhere needed and are more clean than before.
It is now possible to disable the displaying of the search/insert/update buttons at the top of the form through config.php.
It is now possible to change the select operator names (is equal/contains/greater than/less than/starts with/ends with) according to the language
The function that validate URLs now support port numbers, https protocol and four letters primary domain name (e.g. .info).
The validity of a date field is now checked during insert/update.
The word wrap column choosen in config.php now determines also width of the columns in the results table; the width is now fixed and equal for all column.
It is now possible to choose (through config.php) if always wrap words at the $word_wrap_col column, even if it is necessary to cut them.
DaDaBIK now use the $_GET $_POST $_FILES....variables introduced in PHP 4.1.0
The change table select menu is now an auto-submit one (it is possible to disable this feature through config.php, however).
The update statements now use "LIMIT 1" to ensure that only one record is updated, but only if the MySQL version is >= 3.23.
A blank first option is always added to select_single fields when a search form is produced (it is possible to disable this feature through config.php, however).
The select_multiple field types are not handled any more, at least for the moment.
Linking tables contained in different databases isn't handled any more.
DaDaBIK no more display automatically a column sign (":") after each label.
DaDaBIK didn't update correctly a record when the "Other...." option of a select_single field was used.
DaDaBIK produced an error when tried to display the possible duplicates during an insert operation if some field names need back quotes.
DaDaBIK produced an error when the user clicked on a result page link and the current "order by" field needed to be url encoded.
DaDaBIK produced an error when tried to retrieve values of a select_single from another table if some field or table names need back quotes.
Field order changer didn't work properly: field positions weren't shifted correctly.
DaDaBIK check the similarity of records during and insert operation by using a case sensitive function, this was not correct.
DaDaBIK failed to handle properly the upload when the uploaded file name contained a single quote.
DaDaBIK displayed a broken image link if a record containing an image_file field had no images associated. This happened only with MS IE as a browser.
Fixed the bug that produced a "Warning: stat failed...." message sometimes during an upload.
DaDaBIK lost the value associated with the "Other choices allowed" parameter when, from the administration interface, you clicked on "Refresh internal table".
Upload failed when two files with the same name were uploaded in the same time.
Word wrap feature now works also with email and url fields.
Back quotes were used only if the MySQL version was > 3.23.6, even if also MySQL 3.23.6 supports them, now are used if the MySQL version is >= 3.23.6
It was possible, by maliciously changing the HTML of a form produced by DaDaBIK when possible duplicated were found and post it, to bypass fields check.
DaDaBIK didn't show the SQL statement ($display_sql set to 1) related to a search if no records were found.
March 11, 2003
When a record containing an image_file or generic_file field was updated without uploading a new file, the record loosed the link with the old file; this bug has been fixed.
When a user perform a search in a table containing an image_file or generic_file field the "browse" button was displayed by the browser for those fields, this behavior makes no sense; this bug has been fixed.
The field names of the where clause in the update statements were not back quoted, consequently the update failed if the name of the primary key field needed to be escaped (e.g. a reserved word), this bug has been fixed.
The dutch version of DaDaBIK produced a parse error, this bug has been fixed.
It is now possible to choose if you want to delete (both in the database and phisically) a previously uploaded file.
When two or more files with the same name are uploaded, a new name is assigned automatically (e.g. my_file.txt become my_file_2.txt if my_file.txt already exists, my_file_3 if also my_file_2 already exists and so on).
It is now possible to configure DaDaBIK to accept all files (regardless to the extensions) coming from upload.
Since DaDaBIK requires to set magic_quotes_gpc = on in php.ini (which is the default setting), now if magic_quotes_gpc is off DaDaBIK will stop and display an error message.
Novermber 9, 2002
v. 2.2.1 beta
The bug that caused the lost of the correct search results when the user click on a page number, supposed to be fixed in the previous release, is now completely fixed.
The version of the MySQL server is now correctly checked, in this way the "Your database is empty" bug, supposed to be fixed in the previous release, is now completely fixed.
A known bugs document is now available.
October 22, 2002
v. 2.2 beta
Support for file uploading (images and other) is now available.
The bug that caused the lost of the results order when the user click on > has been fixed.
The bug that caused the lost of the correct search results when the user click on a page number has been fiexed.
Fixed the bug that prevented the internal table manager to work correctly when the result order is changed.
The version of the MySQL server is now checked, in this way the "Your database is empty" bug has been fixed.
The numeric type now accepts also float and other numeric fields.
July 31, 2002
v. 2.1b beta
Web and e-mail fields weren't display correctly in the version 2.1 beta. The bug is fixed with tihs version.
July 30, 2002
v. 2.1 beta
A new, lighter and easier to use administration interface (related to the internal table manager) is available.
The form has now a better layout, all the fields are correctly aligned, including dates.
All the translations are now up-to-date.
It is now possible, for select_single fields, to choice "other" during an insert and fill a textbox by hand with an alternative value. That value also update the select options, unless option had driven with a custom query ("SQL:......").
It is now possible to choice if a field has to be displayed in the details page or not.
Completely fixed the bug the caused the warning message: "Warning: Call-time pass-by-reference has been deprecated......" with particular php.ini settings
It is now possible to use the "-" sign and other allowed signs in MySQL table and field names.
Fixed a bug that prevent some text to be displayed if written after a special html char (e.g. <).
Fixed a bug that prevent to choose more than 999 characters as maxlength of a field.
Fixed a bug related to the use of the double quote in the include statements, that can cause error messages.
Textbox and password fields are now checked for max lenght also server side.
Select_single fields are now checked for length and type, this improve security because a malicious user could change the html of the form and then post it.
Jun 28, 2002
v. 2.0.1 beta
DaDaBIK is now compatible with PHP 4.2, and works also with register_global directive set to off.
Added two new date display formats, which fix the problem of displaying dates before 1970
Fixed a bug that caused the insert of a separator if a select_multiple_menu or a select_multiple_checkbox were empty
The "Any/all" conditions menu now appers also in Netscape and other browsers.
Fixed some minor bugs that caused warnings and notices.
Jun 1, 2002
v. 2.0 beta
Support for multiple tables available.
"View all records" feature.
It is now possible to order a group of record by a field clicking on the corrisponding coloumn.
The pages navigation tool has been improved.
Fixed a bug about size of input field in Netscape.
Fixed a bug that about the color of the required fields in the search form.
Apr 21, 2002
Fixed a bug that allowed an attacker to execute arbitrary sql query on the database (e.g. insert or delete records even if insert and delete feature were disabled).
Fixed a bug about double quotes handling in the search function.
All DaDaBIK users are encouraged to update to the latest version.
Apr 15, 2002
Fixed the bug that caused an error during the insert if you didn't enable the check similiarity for any fields.
Fixed the bug that caused a "Required field" message even if a date field was filled by the user.
Fixed the bug the caused a warning message if allow_call_time_pass_reference is set to false in php.ini.
Added Spanish and French versions.
Mar 18, 2002
The algorithm that scans existing records during an insert in order to find similar records is now more efficient (e.g. for a table with >8000 records, 2 fields to check, it is now 5 times faster than before).
Update now works also with a MySQL version < 3.23.x
Fixed the bug that caused an error if a date field was initally null.
Feb 28, 2002
A new administration interface is now available and allows you to manage the internal table without any other software!! So you don't need PHPMyAdmin any more in order to customize DaDaBIK.
Configuration is now easier.
Debug mode added.
Feb 11, 2002
It is now possible to disable the functions: insert, update, delete and details; in this way you can safety use DaDaBIK in a public site.
New administration interface for the internal table.
The installation procedure is now more explicative.
New customizable graphic icons for edit/delete/details buttons.
You can now choice the coloumn at which a text, textarea, password or select sinlge field will be wrapped in the results.
It is now possible to choice the target window for edit/details (self or new).
The graphic layout of the form looks now better with Netscape.
German translation added.
Jan 27, 2002
In the version 1.5 I missed the code line that allow to use the dutch version, the version 1.5b include a fix to that bug together with a config.php file more precise.
Jan 26, 2002
DaDaBIK is now considered out of beta and has some important new features, for this reason I decided to call this release 1.5 (the last was 1.1 beta)
Partial foreign key support: it is now possibile to drive the possible options of a "select_multiple" or "select_single" field from another table, even with a customized SQL query!!
It is now possible to select between any/all the conditions during a search
It in now possible to display a select_multiple field also with a menu (HTML select multiple tag)
For each field you can now specify a prefix value (e.g. http://) and a default value
For each field you can now specify which operator the user can use, including exactly, like, >, <
A Dutch version of DaDaBIK is now available
An on-line demo is now available
Minor bug fixed
The results of a search are now displayed taking the carriage return (\n) into account.
Jan 14, 2002
v. 1.1 beta
According to user's needs, now the internal table and the main table are in the same database, so you don't need two databases in order to run DaDaBIK.
It is now possible to specify the order of a field in the form.
Required fields message now apper only if there are at least one required field.
Search of a "select single" field with exact/like feature enabled now works.
Some updates didn't work, now the bug has been fixed.
Bug about searching by date fixed, now you can search properly a record by date using < or >.
Time generated by insert_date and update_date are now in 0-24 format.
Dec 9, 2001
v. 1.0.5 beta
The configuration file is now more explicative.
The readme file is now more explicative.
A new document about the internal database is now available.
Now you can select between an "exact match" or a "like" search also in the form, on the fly. (You can also disable this feature)
Hints are now visible even during the update procedure
The maxlength property in the internal database now works
A very small part of the function build_form() rewritten in order to make DaDaBIK more flexible.
Dec 5, 2001
v. 1.0.4 beta
The readme file is now more explicative.
Two HTML-related bugs fixed:
the background of an empty cell now appears even with Netscape
the select input field now appear correctly even with Netscape
Dec 1, 2001
v. 1.0.3 beta
Italian version added
Some english mistakes fixed
Configuration option (display the "I think that x is similar to y......" statement during duplication check) added
Nov 24, 2001
v. 1.0.2 beta
One bug fixed (creation of the internal database didn't work due to bug in db_functions.php)
Nov 24, 2001
v. 1.0.1 beta
Several bugs fixed (creation of the internal database didn't work, navigation buttons didn't work)
Nov 21, 2001
V. 1.0 beta
The first release of DaDaBIK.