Support

Account

Register Login

Home › Forums › ACF PRO › 5.5.1 – database update 'loop'

Solving

5.5.1 – database update 'loop'

  • Hiya!

    This is my first post here, thus first off, thanks for this amazing plugin.

    Getting to the subject, I saw at least 2 similar topics, but my case is somewhat different.
    I installed ACF Pro 5.5.1 and it suggested to update the database. I didn’t use ACF before, but I’m using Intense plugin which has ACF bundled with it.

    So I clicked the button, the ‘updated successfully’ message showed up, but ACF kept asking for DB update. Nothing in error logs, I even bumped server resources to 16GB and 4 or 6 cores – no change.
    I have an insane amount of custom taxonomy terms – about 300k (states, cities and zip codes of several countries), but again, I never used ACF before. I’m using Pods though.

    I went ahead and replaced ACF in Intense with 5.5.1 – no change. Deactivated stand-alone ACF – no change.
    Finally, I opened wp_options, found “acf_version” option and changed it to “5.5.1” (it was “5.4.8” before, set by ACF in Intense I guess). Bingo, the DB update message is gone.

    That said, did I do something stupid, or am I good to move on? 🙂

  • I don’t think so, if you can’t disable the acf plugin that’s bundled in the other plugin then I’d contact the author and see if they have a way to do so. On the other hand, the other plugin may not work 100% correctly with the new version of ACF. At any rate, you should talk to the author of the other plugin to find out.

    More than likely the problem was caused because the version of the plugin bundled in the other plugin was actually loading before the stand alone version.

  • There’s no way to disable ACF bundled with Intense, looks like it’s a ‘hard’ dependency.
    Still, even when I disabled Intense (and thus its bundled ACF) – the database update never completed, meaning, it kept asking for update again and again. There was no way for the bundled ACF to load before the stand alone one because I even tried moving the Intense dir out of plugins and this didn’t change anything.

    From the looks of it, the DB update process tried to query all existing taxonomies and terms, and considering the fact that I have 300k+ of those – it simply failed at some point.
    Generally speaking, there was nothing to update, I used Intense to add a single shortcode somewhere in the theme and I highly doubt this shortcode (masonry, https://intenseplugin.com/shortcodes/masonry-shortcode/) actually utilizes the bundled ACF in any way.

    I’ll review your DB update process when I have some spare time, but my wild guess is that if ACF notices a sign of a previous version (e.g. in wp_options) – it’ll attempt to update the DB and it’ll start from querying all available taxonomies and terms. I realize my case is rare, not many of us here keep 300k taxonomy terms, lol.

    However, I did contact Intense guys, they also said this looks weird, partially, because they believe Intense does detect the stand alone ACF and doesn’t load the bundled one if it’s not needed.

    Ok, we’ll see where all this takes us 🙂

  • ACF isn’t mine, I’m just another user trying to help out. It could be correct that ACF is timing out moving all the options to the termmeta table. I just took a look at the update process ACF gets all the values from the options table in a single query but then it updates the values using update_metadata one field at a time. This is where you were hitting the problem. There’s a very good chance that not all of your termmeta got updated properly.

    In this case, this is what I would do. First, I’d revert the site to what it was before the update, if you have a backup.

    The next thing I’d do is add an action on this hook in the update 

    
do_action('acf/update_550_term', $term);

    That would add the term to a local file so that I can see which ones have been successfully updated. This hook is called after updating each term.

    Then I’d try the updating again and doing the db upgrade. When it times out, look in the file and see what terms were successfully updated and then manually delete all of the ACF fields from the options table for those terms. Then do the DB upgrade again. Rinse and repeat until it’s able to complete the process.

    … or rather than manually delete them, in the action filter instead of outputting the term to a file, do a query to delete all of those fields. Take a look at the function acf_update_550_term, the get query used could easily be converted to a delete query.

    Of course, for anyone that’s reading this, make sure you back up your database before trying my advice.

  • John, all that makes sense, except one ‘but’ – I don’t have any term meta in wp_options. All my existing termmeta is in it’s ‘native’ table because Pods implemented termmeta support long before ACF.
    And yes, in case anyone wants to ask, ACF does see termmeta created by Pods and vise versa 🙂

    That’s why I mentioned that I believe there’s actually nothing to update in my case. But I’ll play with that action to see if it produces anything.

    Thanks a bunch for your help!

  • But if you update a term page that has ACF fields, acf would still update the values in the options table and not to the termmeta table. Or does pods somehow detect that ACF is updating a term and override what ACF is doing? I don’t know anything about pods, but I’m quite sure that if you edit a value in an ACF field on a term that ACF 5.4 will put that value into the options table and not into the termmeta table unless something in pods is preventing it from happening.

  • The thing is that I haven’t even started to use ACF for termmeta or for anything else. The very first thing it gave me was DB update message, thus all the fuss here 🙂
    My existing terms don’t have ACF fields, I also checked the whole wp_options table and there isn’t a single sign of termmeta added by ACF 5.4.

  • That’s really odd, and I like puzzles.

    ACF is looking in the database in the options table for anything that looks like "{$taxonomy_slug}_{$term_id}_%", and since it’s a MySQL the underscore can actually represent any character… it’s an error that many people make. At any rate, it’s assuming that anything it finds that matches this is a field and it updates the term with whatever is represented by the %.

    Either it’s timing out during the process somehow or there is some kind of a PHP error happening that’s preventing it from completing.

    Since you haven’t actually used ACF for any fields yet, none of it probably makes any difference whatsoever. Somehow along the way here I was thinking that you had a lot of ACF data that needed to be moved, but now I’m leaning more toward a PHP error that’s causing it to fail.

  • Ok, so you said ACF is looking for things like "{$taxonomy_slug}_{$term_id}_%" in wp_options.
    Doesn’t it have to ‘know’ all existing $taxonomy_slug and $term_id values before being able to look for them in options table?

    If that’s the case – I imagine it’ll try to pull all existing taxonomy slugs and term IDs from the DB first, and that’s the point when it’ll probably choke with my 300k+ items before even being able to do anything else.

    Makes sense?

  • yes, it gets all the taxonomies, loops through them and gets all the terms for each one and then does a db query for each term to get the values from the options table. I see what you’re saying. you have >300K terms. Yah, you’re probably right that’s where it’s choking.

  • So, with everything said above, I assume I’m all good moving forward, ain’t I?
    I updated “acf_version” option to “5.5.1”, basically telling ACF not to try copying termmeta from wp_options to ‘native’ WP termmeta table since I don’t have any in wp_options.
    Or will ACF 5.5.x still attempt to store any new termmeta I’ll add via ACF into both wp_options and ‘native’ tables?

Viewing 11 posts - 1 through 11 (of 11 total)

The topic ‘5.5.1 – database update 'loop'’ is closed to new replies.