$hooks['table']['update']['before'] generates an error

omroepmuseum

Well-known member
You are using DaDaBIK version 13.5-Levanto platinum, installed on 28/07/2026 (installation code: 133315a7493334bfea), the latest version of DaDaBIK is 13.5-Levanto released on 07/07/2026
You are running the latest release of DaDaBIK
In case you want to upgrade to a more powerful edition (from Pro to Enterprise/Platinum, from Enterprise to Platinum) please contact us.

System info​

PHP Version: 8.4.22
mysql version: 10.6.27-MariaDB-cll-lve
Web server: LiteSpeed
Client: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/151.0.0.0 Safari/537.36 Edg/151.0.0.0

Hello,

since 13.5 I have problems with $hooks['table']['update']['before']-functions that used to work before.
As a test, I emptied one of my $hooks['table']['update']['before']-functions (so the function exists but contains NO code at all).
I get following error message:

An error of level 2 was generated in file /home/cj104076/domains/omroepmuseum.be/public_html/DDB/front_logic.php on line 0 by URL: /DDB/index.php?fid=29731&tablename=OMv_voorwerpen&function=update&where_field=id&where_value=489&go_back_after_saving=1
The error message was: Undefined array key "foto_1"

Here is the last known SQL query:
SELECT * FROM `DDB8_row_level_filters` WHERE id_group = :id_group

Here are the query parameters:
Array
(
[:id_group] => 1
)


Backtrace:
Array
(
[0] => Array
(
[file] => /home/cj104076/domains/omroepmuseum.be/public_html/DDB/include/error_handler.php
[line] => 0
[function] => dadabik_error_handler
)

[1] => Array
(
[file] => /home/cj104076/domains/omroepmuseum.be/public_html/DDB/front_logic.php
[line] => 0
[function] => {closure}
)

[2] => Array
(
[file] => /home/cj104076/domains/omroepmuseum.be/public_html/DDB/index.php
[line] => 0
[args] => Array
(
[0] => /home/cj104076/domains/omroepmuseum.be/public_html/DDB/front_logic.php)

[function] => require
)

)


Field foto_1 is the first field following the Primary Key.
The table of the hooks-function does NOT use row level filters.

Kind greetings,

Hendrik
 

eugenio

Administrator
Staff member
I am not aware of any change in v13.5 that may generate an error on a working hook function.

The problem was probably always existent, but now (v13.5), by default, if you enable DaDaBIK error handling, error reporting is set to E_ALL; probably before you had more permissive settings, such as E_ALL & ~E_NOTICE.

foto_1 is an image_file field type? Could you try to remove it from the edit form?

Best,
 

omroepmuseum

Well-known member
Hello Eugenio, I did remove both fields (there are two of them) of image_file field type, and the problem does not occur anymore. However that's not a solution because I need to be able to edit these two fields.
Note: I use this before hook functions to delete the existing image file before replacing it by another one (in order not to have a messy "uploads"-folder with a lot of image files that are no longer used.

Kind greetings, Hendrik
 

eugenio

Administrator
Staff member
Hi,
I will check to see if there is any unexpected behaviour if you use before update hooks in combination with file fields.

About keeping the uploads folder clean, maybe you know that but you can check the "delete" checkbox before saving to delete the current file.

Best,
 

eugenio

Administrator
Staff member
I confirm the problem is with file fields and can be generated under very specific circumstances:
- $treat_blank_as_null = 0
- The file field is not filled
- The NULL checkbox is not checked

Do you confirm? The problem is not related to v13.5, you probably had a more permissive error reporting before v13.5 so you did not see the warning.

Best,
 

omroepmuseum

Well-known member
Hello Eugenio,

OK about:
- $treat_blank_as_null = 0
- The NULL checkbox is not checked

But the file field is, in most cases, not empty!

Kind greetings,

Hendrik
 

omroepmuseum

Well-known member
Unfortunately, I have to correct this answer.
The issue is solved in a very simple table. But if I do the test with the table we use most frequently now, I get an error message - different from the previous one. The error message mentions a select_multiple_checkbox field (not a Required Field).

An error of level 2 was generated in file /home/cj104076/domains/omroepmuseum.be/public_html/DDB/front_logic.php on line 0 by URL: /DDB/index.php?fid=30307&tablename=OM_voorwerpen_alles&function=update&where_field=id&where_value=1&go_back_after_saving=1
The error message was: Undefined array key "selectiecriteria"

Here is the last known SQL query:
SELECT * FROM `DDB8_row_level_filters_beta` WHERE id_group = :id_group

Here are the query parameters:
Array
(
[:id_group] => 1
)


Backtrace:
Array
(
[0] => Array
(
[file] => /home/cj104076/domains/omroepmuseum.be/public_html/DDB/include/error_handler.php
[line] => 0
[function] => dadabik_error_handler
)

[1] => Array
(
[file] => /home/cj104076/domains/omroepmuseum.be/public_html/DDB/front_logic.php
[line] => 0
[function] => {closure}
)

[2] => Array
(
[file] => /home/cj104076/domains/omroepmuseum.be/public_html/DDB/index.php
[line] => 0
[function] => unknown
)

)


User: hendriks-a
Table: OM_voorwerpen_alles
Function: update
Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/151.0.0.0 Safari/537.36 Edg/151.0.0.0
IP: 2a02:1812:110b:ee00:7c76:c666:fa05:1e07

Hereunder a part of Forms configurator for that particular field:

1787934711003.png
Kind greetings,

Hendrik
 

eugenio

Administrator
Staff member
Hello Hendrik,
you are right, it's a similar warning regarding select_multiple_* fields that is generated by an update operation when:
- $treat_blank_as_null = 0;
- the null checkbox is not checked
- the field is left blank

I will fix this bug as well.

Question: is there any particular reason why you set $treat_blank_as_null = 0? DaDaBIK must correctly work even with this setting, I am just asking to understand if you can change this setting and get rid of the warnings before the fix is released.

Best,
 

omroepmuseum

Well-known member
Eugenio,

sorry for the late reply (we are extremely busy both on our database of the old TV-equipment we have and on the TV-equipment itself. If you are interested in some old TV-equipment, please let us know.
About $treat_blank_as_null = 0: the reason to have this parameter this way was related to my own software. But I do not remember anymore to what part of my own software :( I will try to find out (when I find the time).

Kind greetings and thanks,

Hendrik
 
Top