@imrejonk opened this Issue on August 22nd 2019

System information

  • Matomo: Matomo 3.11.0
  • OS: Debian 10.0
  • PHP: PHP-FPM 7.3
  • Database: MariaDB 10.3
  • Web server: NGINX 1.14

We've experienced a database issue after updating to Matomo 3.11.0 from 3.10.0, causing Matomo to stop tracking visits and preventing plugin updates. The database upgrade seemed to be going well, as did our re-run of the database upgrade (as described in the Matomo Update FAQ). Still, visits were not being tracked anymore. Plugin updates failed with "Could not verify the security token on this form". We noticed this error in our NGINX error logs:

2019/08/22 12:02:11 [error] 12672<a href='/12672'>#12672</a>: *137116 FastCGI sent in stderr: "PHP message: Error in Matomo (tracker): Error query: SQLSTATE[HY000]: General error: 1364 Field 'visit_total_events' doesn't have a default value In query: INSERT INTO piwik_log_visit (idvisitor, config_id, location_ip, idsite, visit_first_action_time, visit_goal_buyer, visit_goal_converted, visit_last_action_time, visitor_days_since_first, visitor_days_since_order, visitor_returning, visitor_count_visits, visit_entry_idaction_name, visit_entry_idaction_url, visit_exit_idaction_name, visit_exit_idaction_url, visit_total_actions, visit_total_interactions, visit_total_searches, referer_keyword, referer_name, referer_type, referer_url, location_browser_lang, config_browser_engine, config_browser_name, config_browser_version, config_device_brand, config_device_model, config_device_type, config_os, config_os_version, visitor_localtime, visitor_days_since_last, config_resolution, config_cookie, config_director, config_flash, config_gears, config_java, config_pdf, config_quicktime, config_realplayer, con" while reading response header from upstream, client:, server: stats.bof.nl, request: "GET /piwik.php?action_name=Bits%20of%20Freedom%20%E2%80%93%20Bits%20of%20Freedom%20komt%20op%20voor%20internetvrijheid%20door%20de%20online%20grondrechten%20op%20communicatievrijheid%20en%20privacy%20te%20beschermen.&idsite=2&rec=1&r=897124&h=12&m=2&s=11&url=https%3A%2F%2Fwww.bitsoffreedom.nl%2F&_id=ebe8ce753d6be31d&_idts=1566460057&_idvc=2&_idn=0&_refts=0&_viewts=1566464120&send_image=1&cookie=1&res=1920x1080&gt_ms=538&pv_id=T8ZtGx HTTP/2.0", upstream: "fastcgi://unix:/run/php7.3-fpm-matomo.sock:", host: "stats.bof.nl"

Both issues were resolved after executing this SQL statement against the database:

Could it be that this ALTER TABLE statement is missing in the Matomo 3.11.0 database migration script?

@tsteur commented on August 22nd 2019 Member

The field should be nullable though see https://github.com/matomo-org/matomo/pull/10492/files#diff-1eae80e84fbec709e6e3c03b237656f9R21

In theory this should have just worked? We have basically pretty much all fields nullable. Does it maybe depend on the sql_mode?

@imrejonk commented on September 2nd 2019

Thanks @tsteur, we've made the field nullable in our database as well. That seems to work just as well.

Not sure what effect sql_mode has on these migrations, but here are our current values:

MariaDB [matomo]> SELECT @<a class='mention' href='https://github.com/SQL_MODE'>@SQL_MODE</a>, @<a class='mention' href='https://github.com/GLOBAL'>@GLOBAL</a>.SQL_MODE;
| @<a class='mention' href='https://github.com/SQL_MODE'>@SQL_MODE</a>                                                                                | @<a class='mention' href='https://github.com/GLOBAL'>@GLOBAL</a>.SQL_MODE                                                                         |
1 row in set (0.000 sec)

Would you say these values are okay?

@tsteur commented on September 2nd 2019 Member

@imrejonk it should have already been nullable so it was likely not due to the SQL mode. It seems for some reason it was not nullable on your installation. Maybe there was an issue a while back with Matomo 3 update or some were manually executed. I'll close this issue again as it really looks like all should be working fine from our side. I recommend you maybe check other fields too if they are nullable.

@imrejonk commented on September 2nd 2019

Thanks for the help @tsteur! I suppose it was just a migration issue on our side. I should've mentioned that we migrated our complete Matomo installation to a new system a couple months back. Database went from some old MySQL to MariaDB 10.3. Guess we're going to check all our fields against the database classes to be sure :man_shrugging:

@arisada commented on December 31st 2021

I've been hit with the same weird problem after migrating from a very old piwik installation to the latest matomo. In case someone else needs it, here is the command that fixed it for me:

mysql> ALTER TABLE piwik_log_visit MODIFY visit_total_events smallint unsigned;
Query OK, 833369 rows affected (16.63 sec)
Records: 833369  Duplicates: 0  Warnings: 0

I just hope there are no other unnullable columns waiting to trigger the same bug on a different parameter. So far it seems to work.

@plegall commented on March 1st 2022

I had to perform the same for location_browser_lang:

ALTER TABLE log_visit MODIFY `location_browser_lang` varchar(20) DEFAULT NULL;
This Issue was closed on September 2nd 2019
Powered by GitHub Issue Mirror