-7

In performing the upgrade from 4.5.2 to 4.5.3, a single row used by a plugin is deleted which contains all the data for the plugin. I'm digging through the upgrade and I don't see anything that relates to database changes, especially related to the wp_options table structure which is the same before and after the upgrade.

db_version is the same in wp_options pre and post update.

Restoring the row is possible and everything works fine, but I'm concerned it would happen again.

It is a custom plugin. Source code is not public. I am the developer of it, so I can fix problems.

Does anyone have any idea what could cause this and how to fix it?

Improve this question
3
  • 4
    How could we help you fix code that you are not willing to share with us?
    – cjbj
    Aug 16, 2016 at 7:41
  • @cjbj Willing to share the code and permitted to show the code are separate issues.
    – MECU
    Aug 17, 2016 at 0:30
  • Are you at least permitted to share some code snippets or at least sketches that show how the plugin interacts with wp_actions?
    – swissspidy
    Aug 21, 2016 at 8:57

1 Answer 1

Reset to default
12
+25

It's impossible to help without having a look at your code.

As I am one of the people who worked on WordPress 4.5.3, I can assure you that it's a usual maintenance and security release. There were no database-related changes between these versions except for #36748. Citing the commit message here:

Database: dbDelta() will no longer try to downgrade the size of TEXT and BLOB columns.

When upgrading to utf8mb4, TEXT fields will be upgraded to MEDIUMTEXT (and likewise for all other *TEXT and *BLOB fields). This is to allow for the additional space requirements of utf8mb4.

On the subsequent upgrade, dbDelta() would try and downgrade the fields to their original size again. At best, this it a waste of time, at worst, this could truncate any data larger than the original size. There's no harm in leaving them at their new size, so let's do that.

As you can see, this has nothing to do with the wp_options table which uses LONGTEXT. Therefore I'm sure that the situation you're experiencing must be caused by a bug in your plugin and not something that happened during the update.

But again, it's impossible to know for sure without sharing your source code.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.