Posts Tagged ‘MySQL’

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, 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).

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

%d bloggers like this: