$conf, $runtime; function_exists('chdir') AND chdir(APP_PATH); $r = 'mysql' == $conf['cache']['type'] ? website_set('runtime', $runtime) : cache_set('runtime', $runtime); } function runtime_truncate() { global $conf; 'mysql' == $conf['cache']['type'] ? website_set('runtime', '') : cache_delete('runtime'); } register_shutdown_function('runtime_save'); ?>updates - WP 5 upgrade and ALTER TABLE wp_post ... post_password|Programmer puzzle solving

Programmer puzzle solving

    最新消息：Welcome to the puzzle paradise for programmers! Here, a well-designed puzzle awaits you. From code logic puzzles to algorithmic challenges, each level is closely centered on the programmer's expertise and skills. Whether you're a novice programmer or an experienced tech guru, you'll find your own challenges on this site. In the process of solving puzzles, you can not only exercise your thinking skills, but also deepen your understanding and application of programming knowledge. Come to start this puzzle journey full of wisdom and challenges, with many programmers to compete with each other and show your programming wisdom! Translated with DeepL.com (free version)
    你的位置： HOME>matter>updates - WP 5 upgrade and ALTER TABLE wp_post ... post_password

    updates - WP 5 upgrade and ALTER TABLE wp_post ... post_password

    matteradmin10PV0评论

    I manage the server for a site with 30k+ posts. I've tried to update the site from WP 4.9.9 to current WP 5.0.2.

    The update seems to work correctly, but then the backend becomes very slow, while the frontend keeps working normally.

    After the update mytop shows many ALTER TABLE wp_posts ... post_password ... queries running, and, at the top, a copy operation for ALTER TABLE that takes most of the database time.

    I tried letting it run for a whole day, but it didn't finish and I can't afford longer downtimes in the backend, so I've recovered the whole installation from backup, and now I'm back with WP 4.9.9.

    I know many ALTER TABLE statements in MySQL are implemented as create new table, copy over, delete old table, rename new table, and I assume this is just what I'm seeing.

    However I couldn't find any documentation about that WP 5 update behavior, and I'd be surprised to find out it is actually WP doing that, and no one noticed it yet besides me. More likely I haven't googled properly, or it's not WP to blame, but some plugin.

    Does WP really alter wp_posts table upon upgrade to WP 5? And, if so, what can I do to workaround the problem?

    I manage the server for a site with 30k+ posts. I've tried to update the site from WP 4.9.9 to current WP 5.0.2.

    The update seems to work correctly, but then the backend becomes very slow, while the frontend keeps working normally.

    After the update mytop shows many ALTER TABLE wp_posts ... post_password ... queries running, and, at the top, a copy operation for ALTER TABLE that takes most of the database time.

    I tried letting it run for a whole day, but it didn't finish and I can't afford longer downtimes in the backend, so I've recovered the whole installation from backup, and now I'm back with WP 4.9.9.

    I know many ALTER TABLE statements in MySQL are implemented as create new table, copy over, delete old table, rename new table, and I assume this is just what I'm seeing.

    However I couldn't find any documentation about that WP 5 update behavior, and I'd be surprised to find out it is actually WP doing that, and no one noticed it yet besides me. More likely I haven't googled properly, or it's not WP to blame, but some plugin.

    Does WP really alter wp_posts table upon upgrade to WP 5? And, if so, what can I do to workaround the problem?

    • updates
    • upgrade
    Share Improve this question edited Dec 27, 2018 at 20:51 Lucio Crusca asked Dec 26, 2018 at 21:19 Lucio CruscaLucio Crusca 6883 gold badges9 silver badges29 bronze badges 5
    • Does it occur when you update to 4.9.9? – Krzysiek Dróżdż Commented Dec 26, 2018 at 21:33
    • Sorry, my mistake, I'm already on 4.9.9, not 4.9.8 as stated in my original question. Edited, thanks. – Lucio Crusca Commented Dec 26, 2018 at 22:15
    • can you please share the screenshot? – Tejas Gajjar Commented Jan 3, 2019 at 9:04
    • There are no ALTER TABLE in upgrade_500() or pre_schema_upgrade() targetted for 5.0.2. – birgire Commented Jan 3, 2019 at 9:29
    • create demo URL in the same domain copy all site data into it and try to upgrade there with deactivating plugin one by one it might be a plugin issue. – Tejas Gajjar Commented Jan 3, 2019 at 10:18
    Add a comment  | 

    2 Answers 2

    Reset to default 1

    Maybe I'm blind or I'm overlooking something, but...

    I don't see any tickets related to that subject in any of these releases:

    • https://core.trac.wordpress/query?status=closed&milestone=5.0&group=component&order=priority
    • https://core.trac.wordpress/query?status=closed&milestone=5.0.2&group=component

    I also don't see any DB operations in code:

    • https://core.trac.wordpress/browser/tags/5.0.2/src/wp-admin/includes/upgrade.php#L1820
    • https://core.trac.wordpress/browser/tags/5.0.2/src/wp-admin/includes/upgrade.php#L1946

    So I don't think that these ALTERS come with WP.

    Maybe some plugin (or theme) is responsible for this.

    If I were you, I would create a copy of my site, disable all plugins and set the default theme and then run the WP update. And then I would try to find wich plugin is causing these ALTERS.

    Another way is to grep code of your site and search for any ALTERs in the code. ALTERs are not so common, so maybe you'll find something.

    I think that the problem might be with plugins, not with core (it's almost impossible there was that bug). There is a CODE which makes the problem.

    Please do the following:

    • Deactivate all plugins

    • Try to upgrate to lastest WP.

    • One by one, activate a plugin, and see if it causes/starts the bad behavior. Do this will all plugins (if possible, you should have listed which plugins you use).

    Articles related to this article

    Post a comment

    comment list (0)

    1. No comments so far