Forum Replies Created

Viewing 2 replies - 1 through 2 (of 2 total)
  • The clean conflict test is the most informative thing in this thread, and I think it was read the wrong way round. Deactivating everything found nothing because nothing running is causing this – the dates are already written into those 200 draft rows. No plugin has to be active for them to still be wrong.

    The mechanism: WordPress only resets a post’s date on publish when the draft’s date is still “floating”, meaning post_date_gmt is 0000-00-00 00:00:00. A draft you typed by hand has that. A draft that arrived through an importer, a migration, or a bulk tool usually does not, because those write a real post_date_gmt. Publishing then preserves whatever date is already there, which is why your published products land in the middle of a list sorted by date instead of at the top. It’s long-standing behaviour rather than a WooCommerce bug:
    https://github.com/WordPress/gutenberg/issues/7195

    Three things you can do, cheapest first.

    1. Stop sorting by the wrong column. The products list takes orderby straight from the query string, so this needs no code and changes nothing in the database: /wp-admin/edit.php?post_type=product&orderby=modified&order=desc Bookmark that and your just-published products are at the top, where you expected them.
    2. For the remaining drafts, publish from Quick Edit rather than from the editor. Quick Edit forces the post date to now – it’s a known difference in behaviour, and here it works in your favour.
    3. Only if you actually want the historical dates corrected: update post_date and post_date_gmt on the ones already published. Check your permalink structure first. Products default to /product/%postname%/, which does not contain the date, so this is usually safe – but if yours includes %year% or %monthnum%, changing the date changes the URL.

    Worth saying that the counts were never lying to you. The status change did happen every time. Only the ordering was wrong, which is a much smaller problem than what this thread has been chasing.

    Before you migrate the server, it’s worth separating two failures that produce the same
    notice – they have different fixes.

    1) WP-Cron never fires at all. Check whether it was switched off and never replaced:

    grep -n “DISABLE_WP_CRON” wp-config.php

    define( ‘DISABLE_WP_CRON’, true ); is the recommended setup on a busy store. It only
    becomes a bug when the system cron that was meant to replace it was never added:

    crontab -l | grep wp-cron

    2) WP-Cron fires, but one hook keeps re-queueing. The queue then grows even though cron
    is healthy.

    wp cron event list –fields=hook,next_run_relative –format=table

    If everything is overdue, it is case 1. If only one hook is, it is case 2 – and
    WooCommerce > Status > Scheduled Actions filtered by that hook name tells you which
    plugin owns it. The count climbing back after a manual run points at case 2, which is
    worth ruling out before the migration, because case 2 travels with you.

Viewing 2 replies - 1 through 2 (of 2 total)