Fix: WordPress not detecting updates, wp_options table corruption

I have been trying recently to troubleshoot a WordPress website that was not detecting available core and plugin updates. So I installed WordPress Debug Bar plugin and after enabling WP_DEBUG in wp-config.php I could open the Debug menu from the WordPress admin bar and see some errors being logged.

At the wp-content/wp-debug.log file that I had enabled to log wordpress errors, I could see entries like the following (in mixed Greek/English):

   
[26-Jan-2021 13:15:10 UTC] Σφάλμα Duplicate entry ‘113343’ for key ‘wp_options.PRIMARY’ βάσης δεδομένων WordPress για αίτηση INSERT INTO `wp_options` (`option_name`, `option_value`, `autoload`) VALUES (‘wt_cli_start_date’, ‘1611666910’, ‘yes’) ON DUPLICATE KEY UPDATE `option_name` = VALUES(`option_name`), `option_value` = VALUES(`option_value`), `autoload` = VALUES(`autoload`) από require(‘wp-load.php’), require_once(‘wp-config.php’), require_once(‘wp-settings.php’), include_once(‘/plugins/cookie-law-info/cookie-law-info.php’), run_cookie_law_info, Cookie_Law_Info->__construct, Cookie_Law_Info->load_dependencies, require_once(‘/plugins/cookie-law-info/includes/class-cookie-law-info-review_request.php’), Cookie_Law_Info_Review_Request->__construct, Cookie_Law_Info_Review_Request->check_condition, Cookie_Law_Info_Review_Request->reset_start_date, update_option, add_option

Checking the wp_options table with phpMyAdmin I didn’t see it having an option_id with such a value so I opened up the definition for that table from the sidebar and it seems PRIMARY is an index on that table, while the key is option_id as I originally though.

Did a new search on it and found this article

MySQL – Fix Error – WordPress Database Error Duplicate Entry for key PRIMARY for Query INSERT INTO wp_options – SQL Authority with Pinal Dave

from a guy I already trusted due to other nice articles on databases. It was as it seems a database corruption (guess the index is corrupted) and running

REPAIR TABLE wp_options

was enough to fix it.

So via phpMyAdmin’s SQL Code tab I executed that simple SQL command and suddenly Wordpess could find core and plugin updates again:

MySQL DATETIME vs TIMESTAMP and the year 2038

Judging from MySQL documentation at https://dev.mysql.com/doc/refman/8.0/en/datetime.html, it sounds best to use DATETIME rather than TIMESTAMP if you want your database to be future proof. After all 2038 is only 18+ years away.

The DATETIME type is used for values that contain both date and time parts. MySQL retrieves and displays DATETIME values in 'YYYY-MM-DD HH:MM:SS' format. The supported range is '1000-01-01 00:00:00' to '9999-12-31 23:59:59'.

The TIMESTAMP data type is used for values that contain both date and time parts. TIMESTAMP has a range of '1970-01-01 00:00:01' UTC to '2038-01-19 03:14:07' UTC.

Btw, another issue that sounds problematic, at least conceptually, is that one can use the CURRENT_TIMESTAMP to initialize auto-updated columns with the current datetime (aka NOW()), but since the TIMESTAMP type is supposed to be up to 2038, wonder why the CURRENT_TIMESTAMP would be a difference (aka return a value that would overflow TIMESTAMP columns, but still work fine – aka return the accurate datetime – for DATETIME columns after the year 2038).

https://dev.mysql.com/doc/refman/8.0/en/timestamp-initialization.html

At the very least, I’d avoid mixing those data types in the same database, for consistency reasons.