Title: baltano's Replies | WordPress.org

---

# baltano

  [  ](https://wordpress.org/support/users/baltano/)

 *   [Profile](https://wordpress.org/support/users/baltano/)
 *   [Topics Started](https://wordpress.org/support/users/baltano/topics/)
 *   [Replies Created](https://wordpress.org/support/users/baltano/replies/)
 *   [Reviews Written](https://wordpress.org/support/users/baltano/reviews/)
 *   [Topics Replied To](https://wordpress.org/support/users/baltano/replied-to/)
 *   [Engagements](https://wordpress.org/support/users/baltano/engagements/)
 *   [Favorites](https://wordpress.org/support/users/baltano/favorites/)

 Search replies:

## Forum Replies Created

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

 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[WooCommerce] Product status not updating in admin](https://wordpress.org/support/topic/product-status-not-updating-in-admin/)
 *  [baltano](https://wordpress.org/support/users/baltano/)
 * (@baltano)
 * [1 day, 20 hours ago](https://wordpress.org/support/topic/product-status-not-updating-in-admin/#post-19011329)
 * 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](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.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[WooCommerce] Action Scheduler: Past-Due Actions](https://wordpress.org/support/topic/action-scheduler-past-due-actions-7/)
 *  [baltano](https://wordpress.org/support/users/baltano/)
 * (@baltano)
 * [2 days, 4 hours ago](https://wordpress.org/support/topic/action-scheduler-past-due-actions-7/#post-19011163)
 * 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
   whichplugin owns it. The count climbing back after a manual run points at case
   2, which isworth ruling out before the migration, because case 2 travels with
   you.

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