Start and end dates stays to 0 on identity area

[kyfr59]

Hello,

If I type 1950 or 1950-12-20 or any other dates in the correct format on Identity area > Date(s) > Start (or End), the value isn't correctly stored in the database.

So, when I edit my information object, fields are filled with 0.

It works if I change to field type in database : from DATE to VARCHAR for example.

ATOM 2.6 on Ubuntu 20.04.

[fiver-watson]

Hi @kyfr59, can you give me the full release version number listed in Admin > Settings and the PHP version you are using? Have you tried any steps to resolve the issue - e.g. clearing the application cache, restarting PHP-FPM, etc?

One possibility is the the database SQL modes are not properly configured - you can check them by accessing the MySQL command prompt, or else looking in the configuration file created during installation. See:

• Accessing the MySQL command prompt
• Check SQL modes

Here are the SQL modes we recommend configuring in a file at /etc/mysql/conf.d/mysqld.cnf during the installation process:

[mysqld]
sql_mode=ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION
optimizer_switch='block_nested_loop=off'

If you make any changes in this file (or are adding it for the first time), or else using SQL queries in the MySQL command prompt, remember to restart MySQL after:

sudo systemctl restart mysql

If that's not it, please let me know about anything else that might help us to reproduce the issue locally. For example, we have not tested AtoM 2.6 on Ubuntu 20.04 yet - are there any other changes you have made to the recommended installation instructions? Thanks!

[kyfr59]

Hi Dan,

Thanks for the reply.

After correctly set the sql_mode and restart MySql, my issue persist.

It's probably due to my config :

• ATOM : 2.6.4 - 184
• PHP : 7.4.3
• Mysql : 8.0.25
• Ubuntu 20.04

Note that if I set the field type of event.start_date and event.end_date to varchar directly in the database, the problem is solved.

Hope this helps.

Franck.

[fiver-watson]

Hi Franck,

I consulted with one of our developers, and he felt like the SQL mode was the most likely culprit, but I will try to include a few other suggestions as well.

First I would suggest double-checking that the SQL modes are in fact set properly, and were maintained through the MySQL restart. You can try the following SQL query in the MySQL command prompt to double-check them:

SELECT @@sql_mode, @@GLOBAL.SQL_MODE;

If that's not the case, then you might want to double-check that the CSRF secret token is not set to true. We have enabled CSRF support in AtoM 2.7 but if you downgraded to 2.6 for example, this may be causing issues. Check in apps/qubit/config/settings.yml, and make sure that the csrf_secret value is set to false. If you do make any changes, be sure to clear the application cache (php symfony cc) and restart PHP-FPM afterwards before re-testing.

Finally, it is possible that there are issues with Ubuntu or PHP 7.4 at play here. There are likely more incompatibilities but here is one example (though I don't think this particular one is the cause):

• https://github.com/artefactual/atom/commit/0cf8a06a29879bf360c0acc21ede5ed952540acb

Good luck!