Skip to content

Add error logging#48

Open
NickGreen wants to merge 27 commits into
trunkfrom
error-logging
Open

Add error logging#48
NickGreen wants to merge 27 commits into
trunkfrom
error-logging

Conversation

@NickGreen
Copy link
Copy Markdown
Contributor

Changes in this pull request

  • Add settings page at Settings > Plugin Autoupdate Filter
  • Add logging settings
  • Add logging that writes to a folder in uploads folder, and is viewable on the settings page
  • Rotates logs daily
  • Cleans up logs after retention period (default 15 days)

Example log entry

[2025-02-22T00:08:55Z] Plugin Update Attempt: woocommerce-com-product-bundles 8.3.3
{
    "Status": "Autoupdate blocked",
    "Version Info": {
        "Current Version": "7.1.1",
        "New Version": "8.3.3"
    },
    "Details": {
        "Has Update Package": false,
        "Outside business hours": true,
        "Holiday period": false,
        "Delay passed": true,
        "Updates disabled by OpsOasis": false
    }
}

Screenshot

Screenshot 2025-02-21 at 16 41 50

Testing

There are significant architectural changes to the plugin, so we need to test on a real site for a little while before merging to trunk.

@NickGreen
Copy link
Copy Markdown
Contributor Author

Noting here that I've removed the block of code which Eseban added previously, because I don't think it's correct:

// We've got a release date. That release date could be 10 days ago. So instead of adding extra days,
// make a calculation here to see if time() > $release_date + $delay_days. If so, the update version time is now.
if ( time() > $release_plus_delay ) {
    $release_plus_delay = time();
}

But worth going there if we end up with delay calculation issues.

My understanding is that our desired behavior is:

If we have a release date:

  1. We want the delay to be release_date + delay_days
  2. If that calculated date is in the future, use that date
  3. If that calculated date is in the past, we should still use that date

If we don't have a release date:

  1. We fall back to using the current time (time())
  2. Then add the delay days to that
  3. This is our "first seen" fallback behavior

@NickGreen
Copy link
Copy Markdown
Contributor Author

Protip: if you have this installed on a site and want to test it, but don't want to wait for the wp_update_plugins WP Cron event to run, then you can run it manually with this WP CLI command: wp eval 'wp_update_plugins(); wp_maybe_auto_update();'

@NickGreen
Copy link
Copy Markdown
Contributor Author

Suggested additions:

  • Add a spinning/loading gif while the logs are loading when you select them from the dropdown
  • Set logging to be on by default

@NickGreen
Copy link
Copy Markdown
Contributor Author

Logs currently look like this:

[2025-03-26T16:31:21Z] Plugin Update Attempt: woocommerce-com-product-add-ons 7.7.0
{
    "Status": "Autoupdate unavailable - no update package",
    "Version Info": {
        "Current Version": "6.4.1",
        "New Version": "7.7.0"
    },
    "Details": {
        "Has Update Package": false,
        "Outside business hours": false,
        "Holiday period": false,
        "Delay passed": true,
        "Updates disabled by OpsOasis": false,
        "Package URL": "",
        "Package Response Code": null
    },
    "Update Tracking": {
        "Attempt Status": "Pending",
        "Was Attempted": false
    }
}

SO that if a store is connected to WooCommerce.com, we know the package is available.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant