• Resolved Apfelbiss

    (@apfelbiss)


    Hi,

    on a local copy of a web project (for updating reasons) I recognized a strange behaviour after updating WP-Optimize (I can?t say for sure if I had only updated it or also optimized the database):

    Many WooCommerce product titles were renamed after Wishlist titles.
    Because I wasn’t sure if it was really caused by WP-Optimize or if I only didn’t see it earlier, I installed the Backup from the Live System a second time on the local server (MAMP) and searched for products with wishlist titles.

    Every update went fine – even WP-Optimize. But I recognized, that it said after the update (from 2.1.1 to 2.2.0):
    129.806 orphaned post meta data in your database

    Before the update it was only 129.
    And my fear was right – after optimizing this, many products had titles from wishlists. The wishlist titles itself still seem to be fine.

    I am sure that I didn’t optimized a red action in WP-Optimize in the first local installation. Therefore there should be another reason for this behaviour.

    Because of that I’m now worried and don’t want to update WP-Optimize on the live site until this bug is found and fixed.

Viewing 5 replies - 1 through 5 (of 5 total)
  • Plugin Author David Anderson / Team Updraft

    (@davidanderson)

    Hi,

    No, it’s not that…

    129.806 orphaned post meta data in your database

    Before the update it was only 129.

    This is actually a bug in 2.2.0 which truncates the display of numbers greater than 1000. If you’re seeing 129, it’s really still 129k. We aim to get that fixed in 2.2.1.

    David

    Thread Starter Apfelbiss

    (@apfelbiss)

    Hi,

    okay, that explains the big gap between these two values. But why can I already see the correct value in 2.2.0, when you want to fix that in 2.2.1?

    You have got no explanation for the behaviour in the first local installation, when the data chaos appear without any red action?

    Does the data chaos, in the second installation caused by cleaning up orphaned post meta data, mean that there are relevant errors in the database?
    Because the warning text about the red actions only warns about errors when the server shuts down the same time.

    Thank you in advance.

    Plugin Author David Anderson / Team Updraft

    (@davidanderson)

    Ah, sorry. Wrong way round. It was fixed in 2.2.0 from a previous display bug in 2.1.1. Things over 1000 in 2.1.1 were having anything after and including the comma accidentally not displayed.

    I described it the wrong way round because 2.2.0 had a separate bug of the same type (truncating the display of numbers over 1000), and got confused. But this one was a fix from a previous display error.

    David

    Thread Starter Apfelbiss

    (@apfelbiss)

    Okay, but that isn’t an answer to:

    Does the data chaos, in the second installation caused by cleaning up orphaned post meta data, mean that there are relevant errors in the database?
    Because the warning text about the red actions only warns about errors when the server shuts down the same time.

    Is this bug fixed between 2.2.0 and 2.2.2? In the changelog I couldn’t find anything that explains this.

    I re-imported the old database (from a Backup before cleaning up orphaned post meta data) at the second installation. Then I updated WP-Optimize to version 2.2.2 and made a new cleaning up for orphaned post meta data. Now it worked fine?!

    I hope that this will also work fine at the live system.

    Plugin Author David Anderson / Team Updraft

    (@davidanderson)

    Hi,

    The “orphaned postmeta” optimization runs just one SQL query, which removes rows from the ‘postmeta’ table which have no corresponding row in the ‘posts’ table:

    DELETE pm FROM postmeta pm LEFT JOIN posts wp ON wp.ID = pm.post_id WHERE wp.ID IS NULL;

    That’s not changed since we took over the plugin, and is unlikely to have ever changed in WP-O’s history since it only does one straightforward thing. If it did cause a problem afterwards then it’s very likely that your MySQL server table files on-disk were corrupt. That hypothesis is significantly strengthened by the observation that restoring the backup and doing the same operation worked… because restoring a backup deletes the existing on-disk files (and any corruption therein) and recreates them from scratch.

    David

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Data chaos after updating to 2.2.0’ is closed to new replies.